Multiple provisioners in a Vagrantfile with switch/case hack on ARGV[2] ?

[Benjamin Winter]

Hi, I'm just starting out with Vagrant and I have a question re: supporting multiple providers in a single Vagrantfile.

We have a mix of Windows/Mac/Linux developers, and I'd like to be able to `vagrant up` local VMs (via virtualbox, for the devs with Windows/Mac), remote VMs (via vagrant-aws for demo'ing/testing remotely) and local containers (via docker, for the devs with linux workstations).

Is this possible/practical with Vagrant? This is the minimal Vagrantfile I have so far:

    https://gist.github.com/anonymous/b17afeb8fc1050d4faab

Because vagrant-aws requires a "dummy" box, and the Docker provider requires no box, I used what feels like a horrible hack with the the case statement for ARGV[2].

It works, but I feel like there's a proper way to make this generic (or make the conf entirely provider-specific?) but I'm missing it. Or possibly I've misunderstood something fundamental about what Vagrant offers.

Can anyone point me in the right direction please?

Regards,

Ben.

[Torben Knerr]

Hi Ben,

the basic mechanism is there, Vagrant should be smart enough about figuring out the best provider for every VM without needing to pass the "--provider" flag explictly:

https://github.com/mitchellh/vagrant/issues/3812

As for the ARGV[2] parsing: the docker provider is a bit of a special case as it is usually not configured with a basebox, but you still can provide working docker baseboxes:

https://github.com/tknerr/vagrant-docker-baseimages

(no fedora docker boxes in there yet, but pull requests welcome ;-))

So you basically can define it like this:

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

  config.vm.define 'local' do |cfg|

    cfg.vm.provider :virtualbox do |vbox, override|

      override.vm.box = "bento/ubuntu-12.04"

    end

    ...

  end

  config.vm.define 'ci' do |cfg|

    cfg.vm.provider :docker do |docker, override|

      override.vm.box = "tknerr/baseimage-ubuntu-12.04"

    end

    ...

  end

  config.vm.define 'prod' do |cfg|

    cfg.vm.provider :aws do |docker, override|

      override.vm.box = "dimroc/awsdummy"

    end

    ...

  end

end

And then simply do `vagrant up <vm>` and it would automatically use the correct provider. 

That being said, if it really comes to representing different environments (like local/ci/staging/prod) I personally choose to have a subdirectories with it's own Vagrantfile each, especially if it's a multi-vm Vagrantfile describing a whole stack rather than a single vm 

HTH,

Torben

--
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/8af246ce-717b-4626-989c-5d35cfe6a6ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Benjamin Winter]

Torben, this has hugely cleared things up for me, thank you :-)

As for the ARGV[2] parsing: the docker provider is a bit of a special case as it is usually not configured with a basebox, but you still can provide working docker baseboxes:

https://github.com/tknerr/vagrant-docker-baseimages

(no fedora docker boxes in there yet, but pull requests welcome ;-))

This makes a lot more sense now, depending on how we end up handling the Docker projects I may well be contributing Fedora boxes.

 

[...]

That being said, if it really comes to representing different environments (like local/ci/staging/prod) I personally choose to have a subdirectories with it's own Vagrantfile each, especially if it's a multi-vm Vagrantfile describing a whole stack rather than a single vm 

For most of our projects we're only dealing with single VMs (for standardisation of dev environment more than anything) that deploy to containers in production, but separating out multiple Vagrantfiles makes complete sense for the more complex ones.

Thanks again Torben, your pointers have been a great help.

Regards,

Ben.

[Torben Knerr]

Hi Ben,

very welcome.

As you are speaking of dev environments: if you are interested in setting up Linux Desktop based developer VMs as well, this might be interesting for you too:

https://github.com/tknerr/linus-kitchen

(just pattern-wise, not necessarily content-wise)

Cheers,

Torben

 

--

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/373e0f3c-f917-4c9f-bc43-5e676935215b%40googlegroups.com.