Vagrant 1.4

Other than that, I agree it's almost like just using VBox directly.

As soon as you get this consistent workflow, then you can teach it to your entire organization and the whole company knows that ANY project in the company can be worked on using this workflow without any dependencies on their own machine.

And if ops decides to suddenly change the dev environment from VirtualBox to say... AWS... nothing changes! I've had large companies (200+ developers) switch from VirtualBox to VMware to AWS for their dev environments without their developers ever really noticing.

That is pretty cool.

Of course, on top of this, you get a lot of nice things: you get provisioners, you get automatic network configuration, you get the entire plugin community, you don't have to worry about stability on your own because you tap the collective stability of thousands of users, etc.

But the real power is workflow.

I needed to spin up 5 servers, a load balancer and 2 groups of 2 backend servers. I needed to provision them with Chef, have full name resolution, and be able to access the servers from my host machine.

Here's my Vagrantfile

    Vagrant.require_plugin "vagrant-chef-zero"
    Vagrant.require_plugin "vagrant-berkshelf"
    Vagrant.require_plugin "landrush"

    last_ip_octet = 10
    DOMAIN = "vagrant.dev"

    Vagrant.configure("2") do |config|
      config.landrush.enable
      config.chef_zero.chef_repo_path = "./"
      config.omnibus.chef_version = '11.8.0'
      config.vm.box = "opscode_ubuntu-12.04_provisionerless"
      config.vm.box_url = "https://opscode-vm.s3.amazonaws.com/vagrant/opscode_ubuntu-12.04_provisionerless.box"

      %w{default metrics}.each do |backend|
        (1..2).each do |i|
          config.vm.define "be_#{backend}_#{i}".to_sym do |cfg|
            last_ip_octet += 1
            cfg.vm.hostname = "be-#{backend}-#{i}.#{DOMAIN}"
            cfg.vm.network :private_network, :ip => "192.168.33."+last_ip_octet.to_s
            cfg.vm.provision :chef_client do |chef|
              chef.node_name = "be-#{backend}-#{i}"
              chef.add_role "backend_#{backend}"
            end
          end
        end
      end

      config.vm.provision :shell, :inline => "/usr/bin/apt-get update --fix-missing"
      config.vm.define :lb do |cfg|
        last_ip_octet += 1
        lb_ip = "192.168.33."+last_ip_octet.to_s

        cfg.vm.hostname = "lb.#{DOMAIN}"
        cfg.vm.network :private_network, :ip => lb_ip
        cfg.vm.provision :chef_client do |chef|
          chef.node_name = "lb"
          chef.add_role "lb"
        end
      end
    end

    vagrant up  # build my stack from scratch
    vagrant destroy # destroy my stack
    vagrant ssh lb # ssh into the lb instance
    vagrant provision # execute chef (puppet, ansible, bash, etc)

I'm SURE it's a fine tool and I'm just trying to help you communicating it better. :)

"If you're a developer, Vagrant will isolate dependencies and their configuration within a single ==>disposable<=="

"If you're an operations engineer, Vagrant gives you a ==>disposable<== environment"

All I can infer from the page is that this is a tool for building throwaway/local environments running on VM's on my desktop. But there isn't any context given on how this relates to my production environments, i.e. getting from Vagrant instance to production, there's a disconnect there for me.

[1]: http://docs.vagrantup.com/v2/why-vagrant/

Whether I SHOULD HAVE known about Vagrant, I'll let you decide. ;)

To use docker on my mac I have replaced Vagrant with boot2docker (http://github.com/steeve/boot2docker). I didn't need all the moving parts anyway - the VM is always the same, the application-specific bits are all defined inside the containers.

It's cool to think that the only requirement for anybody to jump into a Gradle project is to have the JDK installed. "git clone <project>", "./gradlew assemble" is all it takes for you to fetch all your dependencies and build the project.

I think it'd be interesting to see if Vagrant could incorporate something like this; it sounds like it would help your use case.

Installing the vagrant-chef-zero plugin, for example, is a real PITA because the dependency resolution doesn't deal with a json dependency correctly leading to it or chef zero failing to load unless you install them in a very specific order.

On the other end of the spectrum, when you're writing a Vagrantfile it's technically almost impossible to know what's going to happen when a user starts it up because of all the hooks plugins can throw in, and you can't tell Vagrant not to load a plugin (which would be an incomplete solution anyways, since I can't know what plugins or plugin versions will have bad interactions).

I know you wrote vagrant, so you have a more inside perspective on this, but as a user and occasional plugin writer, it feels like with a gemfile I can specify a state of the world that's considerably less screwed up than the completely random world any given user's install of Vagrant might be.