“Vagrant: Your New Best Friend” Recap

Jeremy Felt recently talked to the PDXWP dev meetup group about Vagrant. This was our biggest dev meetup to date with approximately 40 people showing up. Moreover, approximately 2/3 of the group was new to the meetup. Jeremy graciously shared his notes from the talk for those who were unable to make it.

• If Vagrant is the solution, what’s the problem?
  • There are two things that bugged the crap out of me enough to finally look for a solution.
  • To set the stage, I, like many other developers out there, was using MAMP in OSX to maintain a development environment of Apache, PHP and Mysql. Before that, when I was on Windows, I used XAMPP. Both are great and provide an easy way to setup a basic environment for testing.
  • But not every configuration in the real world matches Apache, PHP and Mysql. Ask anybody now what you should go with for a highly scalable site and you’ll probably hear about nginx and php-fpm. Get any kind of traffic and you’ll want to think about object caching with memcached instead of APC. The possibilities of server configs are pretty endless.
  • And not only are the possibilities of server configs endless, but the bugs that pop up are different too. One bug will always pop up in an environment that you couldn’t account for when fixing all the others.
  • So that’s the first thing – my development environment did not match my the live environments I was developing for.
  • I ignored this for a while, but the absolute final straw was when I worked on a client site that was going to require a specific proxy_pass setting in nginx to help translate a URL into something WordPress could use without completely breaking everything. The only way forward that made sense was to install nginx.
  • So I started exploring how to install nginx in OSX because OSX is linux based and why not.. right? I found out pretty quickly that it’s an absolute pain. There are a few different methods, and people have definitely gotten it right, but then what?
  • That’s the second thing – I bought a personal computer and now I’m mucking it up with a bunch of server junk that I only need for development.
  • There has to be a better way.
• First things first, Virtual Machines – Virtualization and VirtualBox
  • Per a probably excellently sourced Wikipedia article, x86 virtualization is
    • “the facility that allows multiple operating systems to simultaneously share x86 processor resources in a safe and efficient manner, a facility generically known as hardware virtualization.”
  • Per another probably excellently sourced Wikipedia article, VirtualBox is “an x86 virtualization software package” that is
    • “installed on an existing host operating system as an application; this host application allows additional guest operating systems, each known as a Guest OS, to be loaded and run, each with its own virtual environment.”
  • There is other Virtual Machine software out there, notably products by VMWare and Parallels. I’m not versed enough in the differences to explain software virtualization versus hardware virtualization versus hypervisors, so I’ll leave that to you. Neither VMWare or Parallels work with Vagrant yet, but the forthcoming 1.1 release is expected to provide a framework that will allow support for other VM software in the future. It is also expected to work with VMWare Fusion immediately.
• Introducing the solution – Vagrant
  • Vagrant is open source software for “creating and configuring lightweight, reproducible, and portable development environments.”
  • It allows you to easily run headless VMs in VirtualBox (VMs that do not require any kind of monitor, keyboard, or mouse). Better yet, it allows you to automatically provision these VMs as they are built through the use of Bash scripting, Puppet, or Chef.
  • Magic? Magic.
• How does Vagrant solve our original problem?
  • First, it solves the second problem stated earlier very easily. Every virtual machine created and run in Vagrant is sandboxed away from your computer. If you want to try bleeding edge nightlies of nginx, mysql and php or switch over to a Ruby on Rails implementation or play around with Python, these things are available to you without having to worry about screwing up your machine or without requiring access to multiple servers. In fact, if you’re working with enough system memory, you can run them all at once.
  • And that pretty much explains how it solved the first. I can now setup an environment that matches my production environment exactly. If a client is running with mysql 5.5 and apache, I can do that. If another decided to jump on mysql 5.6 and is running nginx, I can do that too. If I’m working on a site that requires heavy object caching, I can easily fire up memcached.
  • Vagrant provides for the most flexible local development environment out there.
• Before we dive in, quick notes on provisioning.
  • Provisioning is what we use to tell the virtual machine exactly how to start up. We begin with a basic box, add software, and configure as necessary. Vagrant supports several methods of provisioning.
  • Puppet
    • Turning to Wikipedia again
      • “Puppet is a tool designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively. The user describes system resources and their state, either using Puppet’s declarative language or a Ruby DSL (domain-specific language).”
    • I will admit complete unfamiliarity with Puppet. They are a Portland company and I’m looking forward to diving in one day, but right now I’ve been focused on Bash because that’s what I know. If you do use Puppet already when managing server resources, you will more than likely be able to introduce this into your local development process as well.
  • Chef
    • Hey, look more Wikipedia
      • “Chef is a configuration management tool written in Ruby and Erlang. It uses a pure Ruby, domain-specific language (DSL) for writing system configuration “recipes” or “cookbooks”
    • I’ve started using Chef a bit, but I’m still wrapping my head around how to translate the Bash commands I know into recipes and cookbooks. Again, if you’re using Chef to manage server resources, it should be a pretty easy transition to using it locally. Much easier to keep your production and development environments in sync this way.
  • Bash
    • My favorite so far, as I stick with what I know. When using Bash provisioning, you define a series of commands that is run after the machine boots, just like you would type if you started a server from scratch. We’ll walk through this in detail so you know exactly what I’m talking about.
• Questions so far?
• Dive in – step by step.