As the number of developers on a project, the number of projects in an organization, or the complexity of a single project increases, it also becomes increasingly difficult to keep development environments operational. From changing dependencies and differing server versions to developers running completely different operating systems, keeping the process of getting a running development environment sane and repeatable is non-trivial.
Vagrant solves all of this by introducing a common configuration format and workflow for describing and building development environments repeatably across Mac OS X, Windows, or Linux.
Benefits of Vagrant
By choosing to use Vagrant, your projects and organization gain some immediate benefits:
Every developer is now working within identical development environments. This eliminates a large portion of “works on my machine” issues.
Every developer learns and uses the same workflow to manage development environments for every project. Instead of custom READMEs per project, having to ask IT for help, or simply being lost, developers learn that the workflow for every project is identical:
vagrant upto get a development environment, and
vagrant halt(or suspend or destroy) to clean up your environment.
The development environments are now sandboxed within virtual machines. The benefits here are twofold. First, the environments can run on Mac OS X, Windows, or Linux. There is no more struggling with Cygwin or quirks between OS X and Linux. In addition to this, you gain all the sandboxing benefits of virtualization. Multiple projects with potentially conflicting dependencies can even run side-by-side. And it is much more difficult to accidentally break the development environment, since it is safely within a virtual machine.
There are many more benefits to be had by using Vagrant, but the above are benefits gained immediately by simply switching to Vagrant. After switching to Vagrant, you can take advantage of other Vagrant features such as multi-machine and networking to do more advanced things. All of this and more is covered in the Vagrant documentation and book.
Per-Project Configuration, a One-Time Cost
To begin using Vagrant, a project needs a Vagrantfile, the configuration file Vagrant reads that describes how to set up the development environment.
The configuration file is created once and committed into version control along with the project. Because of this, only a single person needs to put forward the effort to switch a project to Vagrant. After the Vagrantfile is in place, the entire team gains the benefits of Vagrant without any configuration.
An example Vagrantfile is shown below:
Vagrant.configure("2") do |config|
config.vm.box = "precise64"
config.vm.box_url = "http://files.vagrantup.com/precise64.box"
This Vagrantfile tells Vagrant to start a development environment that is running 64-bit Ubuntu 12.04 LTS. For more details on the Vagrantfile format, read the documentation on Vagrantfiles.
After creating the Vagrantfile, just run
vagrant up in that directory and in a few minutes you’ll have a fully running virtual machine with Ubuntu 12.04.
Once it is running, you can use
vagrant ssh to gain an SSH console into the virtual machine. The project directory (where you put the Vagrantfile) is synced to the
/vagrant directory within the virtual machine. This lets you continue working on the host machine in whatever editor you’re comfortable with, and the changes sync into the virtual machine.
When you’re done working, a
vagrant destroy will remove all traces of the running development environment from your machine.
This was a very basic example that just introduces the basics of the Vagrant workflow, an example Vagrantfile, and covers the benefits of Vagrant itself. For more information on Vagrant, learn more about it on the website or read the book.