Taming a Linux dev environment with Vagrant

Last November I wrote a small rant on this blog about the frustrations that I’ve had with Linux. Specifically, I outlined what my usual solution is if I can’t get something working after about 15 minutes:

I’m tempted just to toss my VM, get the latest Ubuntu ISO and reinstall from a known-good state. But again, you can only do this so many times before it becomes tiresome.

So, enter Vagrant. Vagrant takes this annoying, manual process that I’d resigned myself to doing from time to time and provides a way to automate it (and, in doing so, mostly replaces the need to). Now, instead of messing around with package managers and permissions, I just specify how I want the server configured in a Vagrantfile and Vagrant goes and creates it for me. And if something gets messed up for whatever reason, the process of blowing the VM away and starting over is fast and painless:

$ vagrant destroy
$ vagrant up

And you’re back in business.

Of course, automated installation of packages is all well and good, but the real power of Vagrant comes as part of a development workflow. When Vagrant starts up the VM, it mounts the directory with the Vagrantfile onto the /vagrant path on your virtual machine, allowing you to make changes to your project files locally with a native editor and have them immediately available on the VM. Gone are the days where you’d have to fire up an editor on the VM or have to constantly copy over the project files - it all just works now.

Having a single point on the VM where everything’s stored also makes it possible to specify things like VirtualHost configurations for Apache. So, when the VM boots, in addition to loading all the required packages, it can also configure the installed servers with the necessary parameters for your project. The scope of this sort of configuration is outside that of the Vagrantfile, but Vagrant has built-in support for Chef and Puppet that you can use to do the job.

Finally, if you commit the Vagrantfile (and whatever associated Chef or Puppet files you might have) to your version control system, you can share that development environment with all the members of your team. If you need to add or upgrade a package, just commit the change, have all members of the team pull and vagrant reload and boom - everyone’s development environment now contains that new change. And in the future when you want to pull up the code from the past, you’ll not only be able to see the code but instantly boot up the development environment as it existed and run it.

The Vagrant team has put together a great Getting Started walkthrough to give you an idea of the power and flexibility Vagrant provides. Personally, I now find Linux a lot more manageable now that I don’t have to worry about stuff getting messed up on my development VMs.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (10)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
« Beware using Camera Connection Kit across time zones | Main | I hate "you should follow me on Twitter" »