Affiliate Disclosure: By buying the products we recommend, you help keep the lights on at MakeUseOf. Read more.
If you’ve ever worked on a Web development project, you know just getting started can be tough. Even if you’re just making a simple WordPress widget, you’re going to need a WordPress instance to work with. That often means working on one somewhere in the cloud, or maybe setting up a local Web server. And if you’re collaborating with anyone, they’ll have to create exactly the same setup, too.
That’s annoying, but it gets worse: If you happen to be working on more than one project at the same time, and both projects use slightly different stacks (different Web servers, versions of PHP, etc.) you may find yourself with a lot to keep track of. Thankfully, there’s a better way: Meet Vagrant, a free and powerful way to create project-specific virtual machines.
The End Result, Or: Why Bother?
The concept behind Vagrant sounds a little tricky at first. You basically spin up a VM that runs your Web server and any related scripts, but your project folder is outside the VM. So you can use whatever text editor and browser you usually work with, and don’t have to put up with a slow VM GUI. The VM just does the heavy lifting: It runs a local Web server and serves whatever files you need.
The appeal is ease of use: Once you have a Vagrant box configured for your project, when it’s time to get coding, you simply go to the project folder and type vagrant up. This boots up the VM, and off you go. When you’re done, shut the VM down with vagrant halt and that’s it – nothing polluting your hard drive and system configuration, it’s all self-contained.
What’s even cooler is that you don’t have to understand how the magic happens: Let’s say you’re part of a three-person development team. Only one guy really knows how to configure the environment (a common situation). In the past, he’d have to set up every machine manually. Now, he can just do it once, and everyone else can type vagrant up and get rolling – sharing code on GitHub (or BitBucket, as Matthew recommends) and coding on the same setup.
Note that Vagrant is meant to work alongside a source control system: You set up your runtime environment in Vagrant, and you use Git for the code. So if someone just has your Vagrant box, they won’t be able to do much with it, because all of your Website’s files would be missing: These are found in a folder outside the virtual machine.
Installing Vagrant and Initializing a Box
Vagrant itself can be easily installed on Windows, OS X, and Linux. Go to the official download page and grab an installer for your OS of choice. You may need to install VirtualBox and Ruby separately, but that depends on your particular case.
Once you have Vagrant installed, it’s time to kick the tires with the default box. Type the following incantation:
vagrant box add base http://files.vagrantup.com/precise32.box vagrant init vagrant up
The first line adds a “base box” to your system, and is going to take a while as it actually downloads the box from Vagrant’s servers. You’re getting the 32-bit version of Ubuntu 12.04, Precise Pangolin. The second line initializes the box, and the third line boots it up.
Assuming it all goes well, your console should look something like this:
You can now type vagrant ssh to ssh into your new box, just to see that it works.
These commands will work from within the folder that contains your Vagrant box (whatever folder you ran vagrant init in). This means you can have multiple Vagrant VMs configured (and perhaps even running) alongside each other – one VM per project, for example.
In itself, this is not the most exciting outcome in the world. I mean, it is neat that you now have an Ubuntu VM running, but you can’t really do much with it out of the box.
To make things more useful, you would either need to set your environment up on this box (installing the Web server and development stack you need), or you’d need to find a pre-existing box that already has much of what you need. Since setting up a development environment is beyond the scope of this article (and changes from project to project), let’s now take a look at the wide variety of existing boxes you can get.
Getting Other Boxes
Even if you do know how to set up the development environment you need, the whole point of Vagrant is that it saves duplication of effort. For example, if you’re a WordPress developer, you need Apache, PHP, MySQL, PhpMyAdmin, and WordPress – and you’re not the only one. In this particular case you could go to a site called Vagrantpress [No Longer Available] and with a few quick lines of code, set up everything you need:
wget -O vagrantpress-master.zip https://github.com/chad-thompson/vagrantpress/archive/master.zip unzip vagrantpress-master.zip cd vagrantpress-master vagrant up
And that’s it – you would now be able to go http://localhost:8080 and see WordPress running. This bit of magic (being able to go to your local host’s port 8080) takes place courtesy of VirtualBox’s bridged Ethernet adapters.
This is just one premade Vagrant box out of hundreds of different boxes floating online. For a large collection, you could visit Vagrantbox.es, which is basically a large table listing the many boxes. Note that Vagrantbox.es doesn’t actually host the boxes – instead, the box files are spread all over the place, large in Sourceforge, Dropbox, or Google Drive folders. This also means they could go down any time, so once you find a box that works for your project, you should make a local copy of it – or better still, export the box you end up working with (as you will doubtlessly make some tweaks and customizations).
Not an End, But a Beginning
This post was not meant as a general guide for Vagrant — that’s what the Vagrant docs are there for. Instead, I hope you now have a sense of what a cool tool Vagrant is, and how useful and approachable it can be. Now go make a box!