Why should I use Vagrant instead of just VirtualBox?

Solution 1:

This is a big question, so I'm going to break it up into three sections.

Vagrant

Vagrant is used to set up one or more virtual machines by:

• Importing pre-made images (called "boxes")
• Setting VM-specific settings (IP address, hostnames, port forwarding, memory, etc.)
• Running provisioning software like Puppet or Chef

Note that it doesn't install software or set up the machine past loading the VM and setting VirtualBox settings. Think of it as a scripting engine for VirtualBox.

Here are some reasons I've seen for using Vagrant over just VirtualBox.

1. Set Up Multi-VM Networks with Ease

Most of the Vagrant power-user content I've read has been about setting up multiple VMs at the same time. Vagrant gives you a single config file to set these up, enabling you to launch all of them with one command.

Say you've configured three VMs to network with each other using static IPs on the 192.168.1.* subnet. You find yourself in a location that is already using that subnet to hand out IP addresses, and your VMs now conflict. With Vagrant, you can simply edit the Vagrantfile and reload the VMs, whereas with VirtualBox you'd have to open the settings for each VM, if not boot each VM and change them inside.

2. Source Control

By putting the settings in a text file, it enables the configuration to be put under source control. Made some changes last week and accidentally broke the image? Just revert the changes and reload the VM. You can accomplish this with VirtualBox snapshots, but it will take up much more space than just a Vagrantfile.

3. Various Platforms

There's a large number of boxes available at sites such as http://vagrantbox.es. This enables you to try various OSes or distributions, applying the same provisioning to set up similar environments. This can help with testing or adding support to new platforms, and would be time-consuming using just VirtualBox.

There are a lot of arguments for using provisioning software, as well as using image snapshots. For additional discussion, I'll point you to Stephen Nelson-Smith's excellent article How to Build 100 Web Servers in a Day.

Solution 2:

In addition to the excellent answer given by Adam, Vagrant ties everything all together. Although Chef and Puppet (and Salt and shell scripts and whatever other provisioner you want to use) are separate things, Vagrant ties it all together and makes it work with just a vagrant up.

That one command will

1. just start the VM if that's all that is needed, but it'll also
2. create the box from your specified base box if that is also not done yet, but if you don't even have the base box on your machine it'll first
3. fetch it from its URL and download it to your machine.

You don't have to think about all that. Let's say you're switching to a different project, one started by a coworker. You just checkout the code from your repo, and run vagrant up, not worrying about downloading ISOs or installing anything, or wondering which version of which distro you need to use for that particular client, or whether you have a copy of a VM that's already got everything you need.

You don't even need to worry about whether they've set things up using Chef or Puppet or just shell scripts. (Okay, so you might need to do a bundle install or otherwise make sure you've got everything installed, but still not a big deal.)

By tying everything together, and providing a unified interface for it all, it can make all but the simplest use cases much much easier. At first you may feel like you're just relearning a new way to do what you're already doing, but once you get deeper into Vagrant use you'll discover you can do much more with much less effort. It'll be well worth the initial time investment.

Solution 3:

Here are two more developer use-cases that vagrant simplifies (over "plain" VirtualBox). I didn't see these use-cases called out specifically in the previous answers.

1. Vagrant helps with the aim of keeping the development and production platforms as close to each other as possible. In an ideal world, you would provision the production environment with THE SAME scripts used to provision the Vagrant VM, minimising surprises at deploy time.

2. Integration tests and continuous integration: Vagrant is easy to control from tests, and therefore entire multi-machine stacks can be easily controlled from tools such as Jenkins when doing test runs.

Yes, "plain" VirtualBox can be used here too - but the conventions used by vagrant make it more simple to set these scenarios up.

Solution 4:

Ability to integrate chef or puppet in with VM provisioning is key. Most Vagrant users will tell you they run 'vagrant provision' and occassionally 'vagrant reload' much more often than 'vagrant up' or 'vagrant destroy'. These tasks indicate the real work is not in spinning up/down VMs but 'managing' them after the fact.

To pose a better question (posed by proficient Chef users, anyway) might be why use Vagrant and not knife with the appropriate plugin (will get to virtualbox plugin, in a moment)? For instance, passing argument values stored in a data bag to a knife plugin is (way) more intelligent, flexible and manageable than juggling one giant Vagrantfile. I typically define my 'dynamic' resources like # of CPUs, amount of memory, which OS to deploy, hostname, IP, routes, etc, in chef databag(s) such that I don't need to keep changing my recipe ;-). Editing a databag through Chef web interface is a really easy data entry task I can give to the most junior operators. With Vagrantfile, your forever modiyfing code and believe it or not - code breaks - which pretty much guarantees you'll NOT be handing off simple changes to Operations staff, ever.

Aside from the fact knife does not yet have a plugin for virtualbox (though I envision one in the not too distant future), there are already plugins for most 'enterprise' virtualization products, including vmware, xenserver and just about every major 'cloud' provider, as well. This means knife is far superior to what Vagrant offers if/when you are ready to move beyond virtualbox. For now, Chef community seems happy to let virtualbox users limp along with Vagrant by not integrating virtualbox apis for a knife plugin. There is a knife-vagrant plugin that does allow for use of data bags to pass arguments. But, it still requires vagrant software and it's monolithic Vagrantfile to function.

So, I'll go out on a limb and say Vagrant is definitely NOT 'better' than Chef with knife; but necesary (for now) if you insist on virtualbox and perhaps 'easier' than managing chef with data bags, provided you have a fairly simple environment to manage.