This is a companion blog post to my presentation at WordCamp Vancouver on August 17th, 2013. You can download the PDF of the slides or read through the following for the context that is often missing when reading a presentation at a later time. WordPress.tv also has a video of the talk posted.

Hi WordPress, Meet Vagrant

Story Time

It was December 10th, 2012, the night of our WordPress developer meetup in Portland, that I decided I wanted to break up with MAMP.

I want to break up with MAMP.

— Jeremy Felt (@jeremyfelt) December 10, 2012

Strangely enough for me at the time, I got a couple replies.

@jeremyfelt have you been keeping an eye on Vagrant?

— Micah Godbolt (@micahgodbolt) December 10, 2012

I’m not sure if I saw this tweet from Micah right away, as my reply didn’t come for a couple hours.

Another, an hour later, was from Tom Willmot, the founder of Humanmade, telling me that Homebrew was where it was at.

@jeremyfelt homebrew is where it’s at.http://t.co/ogVvWp6C

brew install php53 –with-fpm –with-mysql nginx mysql

— Tom Willmot (@tomwillmot) December 10, 2012

He then pointed me to a guide on GitHub that Humanmade uses for all new recruits, this guide being a great compilation of procedures to follow to get Nginx and the like up and running in your local (OSX) environment.

@jeremyfelt pleasure, here’s the guide we give new @humanmadeltd recruits https://t.co/FZH5BFW0

— Tom Willmot (@tomwillmot) December 11, 2012

I immediately fell in love with this idea and started soaking up info. Screw MAMP, I was going to have an Nginx setup on my Mac.

About an hour after this, I finally replied to Micah, telling him that I hadn’t looked at it, but that it looked cool.

Fast forward a couple hours, I had to put most of this aside as I had a day job to concentrate on and breaking up with MAMP needed to wait until after hours. My tweets got more excited and I made my way to the developer meetup in a really good mood.

Justin Sainton, who is actually speaking next in this room, gave a great talk that night with an excellent title, “WP E-Commerce, I Hate You with the Fire of a Thousand Suns“, about the progress that’s been made toward refining the code base and improving the feature set. After Justin’s talk I continued my ranting to a few others about breaking up with MAMP and installing Nginx with homebrew instead. Daniel Bachhuber made a comment along the lines of – “why would you want to install all that junk on your computer?”

This is a good point.

Why would I want to install all that junk on my computer. I turned back to Micah’s first tweet suggesting that I check out Vagrant, determined to give it another chance.

And that’s when it clicked.

I just barely typed in "vagrant ssh" and I'm already scared of the power I have unleashed.

— Jeremy Felt (@jeremyfelt) December 11, 2012

I now have two Ubuntu machines running on my one OS X machine.

This is magic.

— Jeremy Felt (@jeremyfelt) December 11, 2012

"Never trust a man with a butter knife, a plastic butter knife." – words to live by from Big Boi.

— Jeremy Felt (@jeremyfelt) December 11, 2012

And at 11:44pm on December 11th, 2012, 24 hours after my initial amazement, Varying Vagrant Vagrants is launched into the world.

Varying Vagrant Vagrants http://t.co/uAleXBED

— Jeremy Felt (@jeremyfelt) December 12, 2012

And so an obsession began. Developer lives changed. A super long name was shortened to VVV (sometimes I even call it V-trip). And within the next few months I was able to uninstall MAMP completely and convince others at 10up and in the community that Vagrant was the way to go.

My Goals

Which is why I’m here at WordCamp Vancouver. To introduce you to Vagrant and get you obsessed. I want each of you to leave this talk amped up to use Vagrant for WordPress development. And I’m pretty sure it’s going to work. After all, you are at…..

And we all know that this acronym was chosen because…

I should admit that I have some hidden agendas.

While this talk is going to go a long way in showing you a superior development environment that will change your life, there’s much more at stake. This is why you should keep my goals in your head while we go through this. 🙂

• L(inux) – don’t need it. Love it, yes. Don’t need it.
• A(pache) – Nginx is better. We can debate, but it is. Or what about lighttpd?
• M(ySQL) – is great! But for how long? What about MariaDB or Percona? Well, I guess MariaDB fails to make my point, but Percona would leave us with LAPP.
• P(HP) – Ok, that’s sticking around.

You’ve hopefully seen the new develop repository from a couple weeks ago at the beginning of the 3.7 cycles that starts to make use of Grunt for core development. Having a Vagrantfile to provide an agreed upon development environment for testing between versions of WordPress and PHP and MySQL and Apache and Nginx and… would be pretty slick.

We contribute in so many ways as a community to the WordPress project and there is a need for sysadmin contributions. It would be great to have a clear way for those who have sys admin experience to contribute to the WordPress project.

Anyhow, my goals aside.

As we’re covering the ins and outs of Vagrant, I’d like you to also tune in to ways Vagrant can fit into your development work flow, how it may have helped you solve problems faster in the past, and how it’s going to make you solve problems faster in the future.

Before we get into it, I want to exercise some hand raising powers.

• Who here is a developer?
• Who here is a sys admin, or manages servers in some way?
• Who here is a developer and uses MAMP or XAMPP or WAMP?
• Who here is a sys admin, or manages servers in some way, and thinks Apache is better than Nginx?
• Who in the room has installed Vagrant on their machine before?
• Who has used it more than once after installing it?
• Who is using it day to day for their development environment?
• What’s Vagrant?

How Did We Get Here?

I’ll get to what Vagrant is in a bit, but first I’m going to cover what we’ve been working with until now.

Has anyone ever used the term cowboy coding to describe the editing, obviously by others, of code on a live server?

Well, for a long while, cowboy coding didn’t seem so bad.

In fact, the beginning of WordPress development was very much all about it. Quite a few members in the WordPress community learned to code by sharing snippets with each other. If you visit the archives of Matt’s blog, there are code snippets to be found, ready to be hacked into your templates at will.

It was the wild west in the era of open source blogging and white screens were a great way of telling when something bad happened.

Luckily, this didn’t last forever. As familiarity with WordPress, PHP and MySQL progressed, local LAMP environments arrived. Apache, PHP and MySQL all had binaries that could be installed in Windows or Mac and a minimum environment could be setup with relative ease. White screens now had the opportunity to happen locally first and therefore more rarely in production.

Even better, MAMP, XAMPP and WAMP came along and provided a method of creating a stable LAMP sandbox for us to play in with just a few clicks. With the minimum requirements for WordPress development met, things got stable and stale. Having this stable sandbox environment goes a long way when building basic WordPress themes or plugins for customers.

Over the last several years, things have changed quite a bit in the landscape of the web, as they always do.

Nginx became a web server to be reckoned with and is now considered by many to be more powerful and performant than Apache.

Linux, MySQL, and PHP remain for the most part, but other additions like Memcached or Varnish are becoming more useful to WordPress developers to maintain object and page caches as sites are required to scale larger and larger while handling an assortment of traffic patterns.

Now, because of the way technology changes on us, when you sit down at your local machine and develop in a friendly familiar LAMP stack, there’s no guarantee that you’ll end up publishing your code to the same environment.

At the most extreme, it can be like only training in a swimming pool before jumping in to swim across the Pacific Ocean.

Personally, I can go back and find so many hours that were spent troubleshooting things that I could not reproduce locally because my environment did not match some unexpected thing on production.

Now. If you have the right OS, you may have filtered through a barrage of various tutorials online to piece together a sloppy system of manually installed packages that come close to matching your production environment, but good luck when you need to change something or develop a product that needs to exist in a different (or even multiple) environment.

Vagrant is the Magic You’ve Been Looking For

The last of Arthur C Clark’s three rules described in “Hazards of Prophecy: The Failure of Imagination” states that “any sufficiently advanced technology is indistinguishable from magic.”

When I sat down and used Vagrant for the first time, it was magic. I had no idea what was going on, but it was going on and I liked it. And it makes sense that it seem like magic at first because really cool things happen without much effort.

Over the last 8 months I’ve gotten deeper and deeper into what Vagrant is and what it means for development and I can now appreciate it as a piece of advanced technology with many possibilities for expansion and use rather than the magic it started as.

Even so, it still feels like magic.

30000 Feet

Before we get into any detail, let’s back up and cover this from 30k feet with one of my favorite things in the world. An analogy.

Your Computer is a Beautiful Lawn

It starts off well manicured, with nicely defined paths around kept gardens that have some wrought iron fencing around them, helping to keep clean. There may even be a couple police officers hanging out to make sure that nothing bad is going on.

A server is a large, beautiful beach connected to the ocean. So many possibilities for digging holes and building sand castles and creating complex moats for waves to come through to visualize how well your sand castle was constructed.

XAMPP/MAMP is a small sandbox in your yard. You have an old tire, maybe a pail. Some shovels and a few rocks that you can play with. You can test out some structures in the sand if you’d like in preparation for the big beach day. If you get real fancy, you might even drag over a hose to spray down the sand castle just to see what happens.

Installing server software directly on your computer is like having a load of sand delivered to your house and dumped on your front lawn. You can probably do a bunch with it, lay out as if it was a beach and build a sand castle or two, but that well manicured look you started with will go away and over time it’s going to become harder and harder to keep track of where all that sand went.

Vagrant is an extreme sandbox. You can do whatever the heck you want with a beach worth of sand, moving it around and building and getting in trouble. If you flip a front loader or a bulldozer goes crazy and starts running things over, no big deal. Hit the reset button and you get to start over.

And when you’re done for the day, only one command stands between you and the personal computer that remains a beautiful garden.

Ground Level

Now that we have a picture of what we’re shooting for, let’s back up again and start over on the ground.

What is Vagrant?

Well, soon.

First, let’s start with virtual machines.

Virtual machines are fictional computers.

Completely made up stories that have no true hardware, but exist as long as they are described.

Through something known as “platform virtualization”, these fictional computers, or guests are able to use the hardware resources provided to them on a host machine without actually controlling those resources themselves. This allows the fictional computers to have, among other things, a processor, memory, hard drives, and network access. In fact, multiple virtual machines (or guests) can be running on the same host at once, all sharing the host’s hardware in a safe way through virtualization.

Virtualbox is GPL licensed platform virtualization software that provides an interface for managing and using these virtual machines. It takes care of figuring out exactly how all of the hardware on your host machine is made available to any guest machine in a safe way.

Vagrant is MIT licensed open source software for “creating and configuring lightweight, reproducible, and portable development environments.”

Vagrant gives you a method to write the story that describes each fictional computer to be virtualized on your host machine so that you can share the story with others, passing around development environments as if it was code.

Probably the greatest part about all of this is that both Vagrant and Virtualbox have installers available for Mac, Windows, and Linux. This means that as a Mac user, I can pass the description of a fictional computer to a Windows user and we can both be confident that we’re looking at the exact same thing when we boot it up. And while the most popular operating system used inside the virtual machine itself is certainly some flavor of Linux, it’s entirely possible that a Windows or OSX machine can be described and passed around as well.

That’s pretty amazing.

Anatomy of a Virtual Machine Built With Vagrant

Let’s talk about the anatomy of a virtual machine built with Vagrant.

• Host
  • Your local machine is the host. It has Vagrant and Virtualbox installed and a copy of the fictional machine story that’s ready to boot up at any time. The hard drives and network devices belong to it at all times.
• Guest
  • Any virtual machine created through virtualization on your host computer is the guest. It is temporarily using the resources of the host, until you tell it to shut down and disappear.
• Box
  • Vagrant provides a way to package boxes. These boxes contain at least an installation of an operating system as well as some guest additions that help any platform virtualization software communicate between host and guest. This base box can be as heavy or as light as you want. It can be a bare bones Ubuntu or CentOS installation with no server software other than that required by Vagrant to do its job. It could also contain all of the various server packages that you need, Nginx, MySQL, etc..
• Provisioning
  • Provisioning makes having a bare bones box most ideal. This is what helps make Vagrant lightweight and reproducible. I can pass a base box around or share it among several different projects and then pass along unique provisioning scripts that explain and automate how the box should be configured as it boots.

Let’s walk through the step by step of getting a base.

1. Download and install [Virtualbox](http://virtualbox.org)
2. Download and install [Vagrant](http://vagrantup.com)
3. Type `vagrant init`
4. Create and then navigate to an empty directory on your computer via the command line and type `vagrant init`
   • This creates a Vagrantfile file in this empty directory that describes the virtual machine you are looking to start.
5. edit Vagrantfile
6. Type `vagrant up`

This is the magic part.

Through no additional interaction an empty Ubuntu box is available for my use on my computer. All I need to do is go to a command prompt, type `vagrant ssh` and I’m in. From there I can do anything that I would normally do with a fresh server instance.

Provisioning

Here is where provisioning comes in. While a base server is pretty awesome on its own, it doesn’t do too much for us if we have to install all of the server software every time that we boot the machine.

There are a few provisioners enabled with Vagrant by default – Ansible, Chef, Puppet, and Shell, with another one, Salt, almost officially in.

These provisioners help describe the story of the virtual machine that you are building every time you start a new instance. Each offers a similar feature set and mostly differs on syntax and organization. I’ll leave a few links in the slides so that you can familiarize yourself with them later.

Great power lies in the use of these provisioners, especially when pushing server configurations to production. I do suggest sticking with shell provisioning at first unless you are already familiar with something else or using it to configure production servers already.

I should mention that again. Ansible, Puppet, Chef, and Salt are already popular tools for server provisioning. There is a chance that you are or an amazing server admin in your life already has some sort of provisioning script setup that you can use to immediately duplicate production in your development environment. And if this happens, and the configuration is for WordPress, you should totally open source it so that we can all share in the love.

So I’m a bit biased as I’ve been working on this for the last 8 months, but I do think it’s a good and approachable example. Let’s walk through the shell provisioning taken from the open sourced Varying Vagrant Vagrants.

This Vagrant configuration is an opinionated attempt to mimic a fairly common server configuration used for performant WordPress projects. We’ve put quite a bit of work into this and have had an amazing number of contributions from the community already. I really would recommend grabbing this and using it to get your feet wet if not as your daily development environment for WordPress projects. Do note that the Internet today will probably not support the sudden `vagrant ups` of 100 developers, so you may need to wait until you get home.

And now, only a couple minutes stand between my beautiful lawn and having an extreme sandbox up and running. In fact, if I power off the virtual machine without destroying it completely, we’re looking at an extremely short start up time whenever I want to dive in.

And with Varying Vagrant Vagrants, once `vagrant up` is complete, I have everything I need.

An environment with Nginx, PHP 5.4, MySQL, both APC and memcached, the latest stable WordPress, trunk WordPress, WordPress unit tests, WP-cli, not to mention a whole range of smaller tools that make development easier.

I uninstalled MAMP shortly after creating this and haven’t looked back.

I know this might seem a little crazy on the outside for some of you. Who wants to spend all that time in the command line, right? You should know that once everything is configured in the provisioning script, there’s little chance that you’ll ever need to go into the command line via `vagrant ssh` if you don’t feel like it. Just develop as normal on your local ‘host’ machine and view the changes in the browser. The only commands you’ll need to issue are those to start and stop the Vagrant. And rumor has it that a GUI is possible for these in the future.

Why should you develop in an environment that matches production?

Vagrant allows you to version control your environment. In fact, the project I’m working on now started with a Vagrantfile.

At Washington State University, we’re in the beginning stages of a project that intends to provide a central publishing platform based on WordPress for any college or department inside the University to use.

I started the repo with a Vagrantfile.

Once I had that, I was able to add WordPress in and then start making the customizations we’re looking for through various plugins and configuration changes.

Now, as we work toward a place where the server architecture is finalized, we can adjust the development environment in the project repository as needed to see if any new problems arise while we continue to build out and use existing code. With the development environment under version control, we can document reasons for software changes or revert to something earlier if an issue does come up.

Vagrant allows you to share your environment. The ramp up time for developers on the project is almost nothing. Just a git clone separates them from having a full, matching development environment on their local machine. No risk to the server. No worry about the developer being on Windows or Mac or Linux.

Imagine working for a customer that is going to host their site on WPEngine and knowing with absolute confidence that the theme you created locally will work without issue.

Or knowing that customers using default WordPress installations on Dreamhost or Bluehost will have not troubles using the plugin that your about to publish to the WordPress plugin repository.

I should stress that while Vagrant is very much going to replace MAMP for you, it is not a MAMP replacement.

Because that’s not what you should want. Instead of one environment restricted to technology that the community needed years ago, you should want a flexible environment that can adapt seamlessly to the technologies that the community must work with today.

Rather than meeting the WordPress minimum requirements we talked about earlier, Vagrant provides a flexible way for a developer to meet their project’s environment requirements.

Wrap Up

• Magic?
• Advanced technology?
• Ready to start using Vagrant on a day to day basis?

I really hope you go home and go through your first vagrant up and then tell me about it later, because it’s a wonderful experience to see how quickly your development can change with a new, more carefree environment.

Resources

• You can find the open sourced VVV at http://github.com/10up/varying-vagrant-vagrants
• You can download the latest version of Virtualbox at http://virtualbox.org
• You can download the latest version of Vagrant at http://vagrantup.com
• Feel free to ping me with questions at @jeremyfelt or find my email on my contact page.
• You’ll soon be able to find work from Washington State University on GitHub