orchestration in vagrant

[Joaquin Menchaca]

Is there any way to apply a provisioning script after all systems are fully up and running in a multi-machine setup.  I have scripts that would need to run, but have to fetch information from other systems that should be online before the provisioning script is run.  I would like to use the built-in provisioner.

Thus in snippet below, wonder if there is a way to run the provisioning after all systems are up?

Vagrant.configure("2") do |config|

  # workstation node

  config.vm.define "work" do |work|

    work.vm.box = "hashicorp/precise64"

    work.vm.hostname = "workstation01"

    work.vm.network "private_network", ip: "192.168.50.4"

    work.vm.provision "shell", path: "setup-work.sh"

  end

  # server to configure

  config.vm.define "server" do |server|

    server.vm.box = "hashicorp/precise64"

    server.vm.hostname = "server01"

    server.vm.network "private_network", ip: "192.168.50.5"

    server.vm.provision "shell", path: "setup-server.sh"

  end

end

[Alvaro Miranda Aguilera]

Hello,

Vagrantfile is read top to bottom.

So if you need the worker after the server put them in different order.

server
node


If you want one script to run in all the nodes, put a
config.vm.provision "shell" after the 2nd box, and that will run at
the end.

here the rule of "inside" > "outside" will apply.

Vagrant.configure("2") do |config|

# server to configure
config.vm.define "server" do |server|
server.vm.box = "hashicorp/precise64"
server.vm.hostname = "server01"
server.vm.network "private_network", ip: "192.168.50.5"
server.vm.provision "shell", path: "setup-server.sh"
end

# workstation node
config.vm.define "work" do |work|
work.vm.box = "hashicorp/precise64"
work.vm.hostname = "workstation01"
work.vm.network "private_network", ip: "192.168.50.4"
work.vm.provision "shell", path: "setup-work.sh"
end

#at this point all the vms have been configured and the local
scripts have been run
config.vm.provision "shell", path: "post.sh"
end

If you require a script, to run in the server after all the workers
have been setup, I will say the easiest way will be make the script to
check host name. Same goes to run something in all the workers but not
on the server

If you need a 2nd pass after the first post run :D just add a second
script. etc.


in the script you can use something like

if [[ "${HOSTNAME}" =~ "workstation" ]];then
echo "doing something here for workstation"
if [[ "${HOSTNAME}" =~ "server" ]];then
echo "doing something here for server"
else
echo "don't know what to do for this box"
exit 1
fi

Hope this helps
Alvaro.

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> IRC: #vagrant on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vagrant" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vagrant-up+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vagrant-up/ac0900cc-c430-4796-827c-c71a5104c38b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Nimon Ambient]

I understand what you're after here, Sadly I'm not sure myself but my example is building a salt server, two clients and then after the fact needing to then accept the requested keys on the salt server, which can only be done after the workstation has sent them, ie: after every box is up.

So an inline script on the box like Alvaro mentioned won't do the trick as the master won't know how long it takes the clients to provision but it needs to be up first to recieve the keys.

[Alvaro Miranda Aguilera]

Hello Nimon.

Joaquin did share his script to how he did it finally.

Did you saw that?

[Joaquin Menchaca]

What I did now is use the order of the servers to keep it servers, so A, then B, then C.   A problem can still arise if C needs something from A, but then A needs something form C after it gets it from A... :)

Right now I don't have such a complex orchestration scenario, so I just swap the orders.  I am doing an experiment with Chef Server, Workstation (knife), and 1+ nodes to configure, all on a private Virtualbox network, and using ssh tunneling to access the GUI on the Chef Server.   It is working pretty well.

[Alvaro Miranda Aguilera]

Hello There

Just to same you some time here.

Vagrant have 2 execution order.

One is top to bottom and other is outside to inside


But the vagrantfile will get evaluated and then executed, so even if
you put blocks before/after they will follow this rule.



output:

==> serverc: serverc
==> serverc: global before
==> serverc: serverc
==> serverc: global after
==> serverc: serverc
==> serverc: serverc
==> serverc: local inside1
==> serverc: serverc
==> serverc: local inside2

Vagrantfile
#global before
config.vm.provision "shell", inline: "hostname; echo 'global before'"
["servera","serverb","serverc"].to_enum.with_index(1).each do |vm_name, i|
config.vm.define vm_name do |server|
server.vm.hostname = vm_name
server.vm.provision "shell", inline: "hostname"
#local
server.vm.provision "shell", inline: "hostname; echo 'local inside1'"
server.vm.provision "shell", inline: "hostname; echo 'local inside2'"
end
end
#global after
config.vm.provision "shell", inline: "hostname; echo 'global after'"
end

So as you can see a global after gets executed before those locals.

So that can be used on global before to setup all the boxes
local inside to do specific task if required

Without getting to complex, what you can do is make your server reach
the other one as part of the provisining

Open to ideas of ppl in the news if they can share some trickery :D

Alvaro.

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> IRC: #vagrant on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vagrant" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vagrant-up+...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/vagrant-up/15f75759-9fc7-4509-8ccf-435044d4c3ca%40googlegroups.com.