Tagged Vagrant

2013-07-07 14.15.17

v1.1 of Varying Vagrant Vagrants has been pushed

0

This is a smaller release in the grand scheme of things, though the first (!) as a new organization. The milestone has been ready for several weeks now. Thanks goes to Aaron Jorbin for prodding it along. :)

Quite a bit has been stable since v1.0, so we’re in a good spot to make a couple big changes in the next release including PHP 5.5.

From the changelog:

  • Transition to Varying Vagrant Vagrants organization.
  • Add a CONTRIBUTING document.
  • Add --allow-root to all wp-cli calls in VVV core.
  • Use a new global composer configuration.
  • Add zip as a package during provisioning.
  • Introduce a helpful caveats section.
  • Remove tcp_nodelay config in Nginx. Reasoning in 0cce79501.

As always, feel free to stop by and open an issue if there’s something you’d like to see!

DSCN6618

A Varying Vagrant Vagrants Organization

3

This is a very transformative moment for the Varying Vagrant Vagrants project.

About a week ago, I reached out to Jake with a proposal to move VVV from under the wing of 10up to an organization of its own. We’ve been cruising along for just over a year, have around 125 unique visitors on the repository a day, and have a nice regular community of contributors. We have received pull requests from just around 40 contributors (!!!) and the issues are constantly a lively place of discussion.

Jake immediately agreed and we were able to talk through the process and the future very quickly. 10up has been a gracious and excellent host for VVV this entire time—the farewell post is great—and I’m looking forward to future steps we can take as a community now that we’re on our own.

I’d like to think that the goal to bring Vagrant to the forefront of WordPress developers’ minds has been accomplished. Through VVV and other related projects, the use of a development environment that closely matches production has come a long way.

I do think that VVV is the best tool out there for contributing to WordPress core. We provide stable, trunk, and develop versions of WordPress and everything needed to run the Grunt build tools and PHPUnit unit tests.

With that in mind, I think we should be able to line up a few goals.

  1. Continue being the place for a WordPress core development environment. This primarily means that we stay on top of the tools that core introduces into the development flow. Providing an approachable way to use these tools and documentation will go a long way.
  2. Directly related to goal one, some of the advancements we make should be around testing multiple versions of everything. If we can make it easy to fire up a PHP 5.x environment and test Nginx or Apache with WordPress 3.x or 4.x, that would be amazing.
  3. VVV has an excellent method for auto site setups. Over time we’ve had some nice demand for a few that could help quite a bit. It would be great to see a couple that provide basic setups for WordPress multisite and WordPress under Apache rather than our default of Nginx.
  4. Bring other tools to the forefront of WordPress developers’ minds. It may be great to see versions of VVV that harness Salt, Puppet, or Chef rather than the bash scripting that we’ve forced upon the project so far. VVV has an opportunity to be a learning tool for all of us in exploring methods of testing, provisioning, and deployment.

Right.

So please chime in with any suggestions that you may have. I’d love to toss the keys to a few new repositories over to anybody that’s interested in building out new tools. Feel free to use the main VVV repository under the Varying Vagrant Vagrants organization to open an issue and discuss your thoughts. We can split things off as needed.

Over time we’ll get more organized and setup a more official forum for discussions as well as some contributing guidelines. I’m going to reach out to a few regular contributors and get them added as committers. We also need to spend some time with licensing to see if we can get away with GPL for everything or if another would be more applicable to the work that we’re doing.

That’s that. Thank you all for being so great. Here’s to the next year of VVV. :)

Luminaries

VVV Turns One

6

A year ago yesterday, I decided I wanted to break up with MAMP.

A year ago today, the Varying Vagrant Vagrants repository was created after an exciting couple nights pounding away at a server config that allowed me to troubleshoot WordPress in Nginx on a local virtual machine.

Since then, VVV has had almost 750 commits from 36 contributors (!!!) on 121 pull requests. The project has been forked 135 times, has 61 watchers and 440 stars.

What a pretty cool year it has been.

Did I mention 36 contributors? On an average of about once every 10 days, somebody decides that VVV is interesting enough to stop what they are doing and submit a pull request containing an improvement.

This blows my mind. Thank you all.

Version 1.0

And now we’ve reached our 1.0 release, which brings us one of the coolest features yet thanks to a wonderful effort from Weston Ruter and Simon Wheatley.

Auto Site Setup

Auto Site Setup allows for projects to be picked up automatically by VVV with custom web structures, host names, Nginx configurations, and provisioning scripts. If you dig into the wiki page explaining how to get started, you’ll get an idea of how powerful it can be.

From a project version control standpoint, it’s fun to geek out about how this came together through a pull request of a pull request of a pull request.

Vagrant Up Just Works

For quite a while, if you ran `vagrant up` on a machine that had been halted, you would also have to run `vagrant provision` in order for all of the services to start up properly.

Version 1.0 is so much happier.

At this point `vagrant up` just works and your workflow can start to match exactly what is expected of a machine that is powered off rather than actually destroyed.

As a side effect of this change, we now copy our config files to the virtual machine from mapped drives on the local machine rather than symlinking them. This may cause some confusion at first if you’re used to changing the configs and having them immediately reflected, but it makes a lot more sense from a provisioning and state management standpoint. This is where `vagrant provision` can be used liberally to reapply any changed config. Commit 1fbf329 contains a more detailed description of the decision and the implementation.

Other Changes

  • Begin implementing best practices from Google’s shell style guide in our provisioning scripts.
  • Databases can now be dropped in phpMyAdmin. Pro-tip, drop database wordpress_develop in phpMyAdmin followed byvagrant provision clears your src.wordpress-develop.dev for reinstall.
  • Allow for dashboard-custom.php to override the default dashboard provided by VVV

Next?

We’re still moving forward. Check out the 1.1 milestone report on GitHub to see what’s in store for the next version and feel free to jump in with pull requests or questions. As part of a greater community of Vagrant users in WordPress, there is also a newer WordPress and Vagrant mailing list that has had some activity. Feel free to stop by and ask any questions there as well.

Vagrant Error in OSX: There was an error while executing `VBoxManage`, a CLI used by Vagrant for Controlling VirtualBox

2

I got the following error earlier in OSX when launching my powered off VVV instance with `vagrant up`:

There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.
Command: ["hostonlyif", "create"]

Stderr: 0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to create the host-only adapter
VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterface, interface IHostNetworkInterface
VBoxManage: error: Context: "int handleCreate(HandlerArg*, int, int*)" at line 66 of file VBoxManageHostonly.cpp

I was able to fix this by running the following:

cd /Library/Application\ Support/VirtualBox/LaunchDaemons/
sudo ./VirtualBoxStartup.sh restart

This reset the services used by Virtualbox and allowed Vagrant to talk correctly to the virtual interfaces again. My guess is that this would help solve related errors as well, not just the one that I received.

Salt Mound image via Alicia Nijdam-Jones

The First Few Things I’ve Learned About CentOS and Salt (In Vagrant)

2

I’ve been doing quite a bit of work this week in provisioning a development environment using CentOS, Salt, and Vagrant. There are few things I ran into along the way that were interesting enough to remember for a later time.

Disappearing Guest Additions

By default, Salt calls `yum -y update` during the process of installing itself. This, depending on your yum configuration, updates every package with an update available–including the kernel.

When the kernel is updated, it seems that the Guest Additions required by Virtualbox for proper communication between the virtual machine and your local machine get lost in the shuffle. Once they do, the box will not fire up again properly until after a `vagrant destroy`.

To get around this, I created a custom yum.conf file that excludes kernel updates by default. This file is synced over to the virtual machine through shell provisioning before Salt is initiated. As you can imagine, this significantly reduces the time spent provisioning the box as well.

In the future I’ll have to figure out if we can find or package a CentOS box that has a newer version of the kernel already installed.

Disappearing Salt Installation Script

Salt has a great installation process available where you can feed bootstrap.salt.org directly into a shell script. This URL currently redirects you to the shell script’s location inside a GitHub repository. When the script runs, it automatically detects what packages are required on your machine and determines how they should be installed.

Unfortunately, GitHub returns a 404 every so often when calling the URL repeatedly via Vagrant’s use of Curl. This means that when first building out your configuration and doing a lot of `vagrant destroy`/`vagrant up`, things fail quite often when Salt can’t install itself on the box.

Luckily, you can specify a custom bootstrap script to run in Vagrant. I copied the version verbatim from Salt’s GitHub account and now include it locally with the WSUWP Environment.

As a bonus, this allowed me to do one extra thing. The process of installing Salt through Vagrant uses the current stable version of Salt for your Linux distribution. I was able to force the use of ‘testing’ packages in the bootstrap script so that my CentOS box would have Salt 0.17.1, rather than the stable RPM for 0.16.4.

Over Firewalled

As an Ubuntu user, the common–well, to me at least–default use of iptables in CentOS always confuses me. Account for this when provisioning and provide some default rules. Things like incoming HTTP requests are blocked by default. This can be annoying if you aren’t expecting it and start troubleshooting problems that you think are with Nginx.

Picking a CentOS Vagrant Box

I first used the nrel.gov minimal box from vagrantbox.es, but MySQL 5.1.69 was preinstalled and at the time it seemed like I had to uninstall all of those packages before reinstalling with the 5.5 packages. It’s possible that the repositories I settled on (see next point) would have made it easier to upgrade, but I got the impression that the box had other preinstalled stuff and I decided to switch. The Puppet Labs box, even though I’m using Salt, has been exactly what I’ve needed thus far.

Better Server Software Repositories

The default repositories for CentOS 6.4 are still on PHP 5.3 and MySQL 5.1, which is a little lame. Thanks to the recommendation of Zach Brown, I went with the Remi repositories for installing PHP, MySQL, and Memcached. For Nginx, we’re able to use a repository maintained by Nginx directly. Both of these repositories have been great so far.

IMG_1818

v0.9 of Varying Vagrant Vagrants has been pushed

0

And it has one heck of a changelog.

Go get it!

It took us 105 or so days, we added about 200 commits, went through somewhere around 10 Vagrant releases, and things are looking sweet. The last few months have been great preparation toward a couple bigger features that are slated to be part of version 1.0 in the coming months.

What’s the best part?

We crossed 30 contributors and 100 forks. The community around VVV has been fantastic to work with.

So yeah, here’s the awfully long changelog of great things that made it into the v0.9 release. Keep your eyes open for v1.0!

  • Possible Annoying: Use precise32 for the Vagrant box name for better cross project box caching.
    • Note: This will probably cause a new Vagrant box to download. Use vagrant box remove std-precise32 after avagrant destroy to remove the old one and start with this.
  • Possible Breaking: Change VM hostname to vvv.dev
    • Note: If you had anything setup to rely on the hostname of precise32-dev, this may break.
  • Possible Breaking: Change MySQL root password to root
    • Note: If anything is setup to rely on the previous password of blank, this may break.
    • You can also now access mysql -u root without a password.
  • Introduce support for the WordPress develop.svn
    • This was added pretty much the day it was available. Such a pleasure to work with!
    • Allowed us to remove the old wordpress-unit-tests in favor of the new wordpress-develop/tests
  • Introduce support for the Vagrant hostsupdater plugin
    • Use vagrant plugin install vagrant-hostsupdater to install.
    • Very, very much recommended for an easier and happier life.
  • Introduce Postfix with a default config. Mail works! (But check your spam)
  • Introduce the WordPress i18n Tools, including config/homebin/makepot
  • Introduce PHP_CodeSniffer, WordPress-Coding-Standards, and Webgrind
  • Remove entire well intended but not so useful flags system
  • Rather than include PHPMemcachedadmin in the VVV repository, download it on initial provision
  • Verify support for Vagrant 1.3.5 (as well as 1.2.x) and Virtualbox 4.3 (as well as 4.2.x)
  • Move xdebug_on and xdebug_off controls to executable files in config/homebin
  • Generate vagrant_dir in Vagrantfile for accessing relative file locations
  • Add a basic network connectivity check by pinging Google DNS servers
  • Update stable version of WordPress automatically on provision
  • General cleanup to screen output during provisioning
  • Many updates to the default nginx configuration
  • Remove poor, unused implementation of Watchr
  • Provide default certs for SSL in Nginx
wcyvr-2013.001

WordCamp Yes, Vagrant Rocks #wcyvr

3

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

wcyvr-2013.003

wcyvr-2013.004

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.

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

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.

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.

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.

wcyvr-2013.010

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?”

wcyvr-2013.011

wcyvr-2013.012

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.

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

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…..

wcyvr-2013.017

And we all know that this acronym was chosen because…

wcyvr-2013.018

I should admit that I have some hidden agendas.

wcyvr-2013.019

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. :)

wcyvr-2013.020

  • 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.

wcyvr-2013.021

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.

wcyvr-2013.022

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.

wcyvr-2013.023

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.

wcyvr-2013.024

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.

wcyvr-2013.025

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.

wcyvr-2013.026

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.

wcyvr-2013.027

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.

wcyvr-2013.028

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

wcyvr-2013.029

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

wcyvr-2013.030

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

wcyvr-2013.031

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.

wcyvr-2013.032

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.

wcyvr-2013.033

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.

wcyvr-2013.034

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.

wcyvr-2013.035

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.

wcyvr-2013.036

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

wcyvr-2013.037
Photo by Steve Snodgrass

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?

wcyvr-2013.038

Well, soon.

First, let’s start with virtual machines.

Virtual machines are fictional computers.

wcyvr-2013.039

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

wcyvr-2013.040

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.

wcyvr-2013.041

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.

wcyvr-2013.042

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.

wcyvr-2013.043

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

wcyvr-2013.045

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.

wcyvr-2013.047

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.

wcyvr-2013.048

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.

wcyvr-2013.049

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.

wcyvr-2013.050

wcyvr-2013.051

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.

wcyvr-2013.052

Why should you develop in an environment that matches production?

wcyvr-2013.053

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.

wcyvr-2013.054

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.

wcyvr-2013.055

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.

wcyvr-2013.056

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

A WordPress Core Vagrantfile

3

Vagrant is a very refreshing tool.

Once the Vagrantfile and provisioning of a project is setup, new developers can join a project and start developing immediately without worrying much about a local setup. DevOps and sysadmin folks can continue to tweak servers and various configurations, passing those changes on to the development team without interruption. Over time, the local development environment comes closer and closer to matching the project’s production environment and those annoying bugs that creep up when the two are different start to disappear.

A bunch of people in the WordPress community have done a ton of great work with VVV over the last 7 months and it’s great to see the traction that it’s gotten. It is a great example of a very useable and modern WordPress production environment and I think will continue to go a long way toward upping the game of many.

Next.

An open source project that ships with a default Vagrantfile is very refreshing.

The barrier to entry becomes so low. Within a matter of minutes, a virtual machine can be launched that provides the operating system, server software, and configuration needed to get started with development and to view the results of the changes that you are introducing. This gives everyone developing for the project a common baseline, helping to avoid worksforme bugs and allowing things to progress faster.

Take a look at projects like DiscourseCouchDBElasticsearchPiwik, and Gitlab for great examples of how Vagrant is currently used as part of core development.

Now. Imagine a WordPress core that ships with a Vagrantfile of its own. Anybody wanting to contribute to WordPress or to work in an optimal environment for building a plugin or theme that can run on any WordPress installation would have the ability to use a virtual machine that the community has decided is valid for development and comprehensive testing.

The possibilities of what could be included in that environment are pretty slick.

  • WordPress Unit Testing is one of the coolest things that VVV currently provides. Giving anyone who wishes a unit testing environment without having to worry about installing PHPUnit locally would go a long way in getting more WordPress developers to test.
  • Scripts that generate core documentation on the fly can be included with the Vagrant configuration, helping developers to explore the core code base more on their local machine.
  • Tools and guides for patch creation, even scripts that automate some of the processes that come with Trac interaction, would help lower the barrier to core contribution.

Granted there are hurdles.

WordPress, along with most other PHP projects, is forced to support multiple versions of PHP. And while web server versions don’t matter as much, it’s still nice to know that both Apache and Nginx are working well, especially when various issues are being dealt with in the world of rewrites. That said, there are ways to provide a flexible environment that can accomplish all of this.

And when we do!

Being able to switch from PHP 5.2 to 5.5, from WordPress 3.6 to trunk, or from Apache to Nginx on the fly to make sure your plugin is compatible with each will be an absolute dream.

All achievable with two steps: Check out WordPress, type vagrant up.

Grand ideas aside, the first goal is to exist. I’ve started a new repository on GitHub, WVand it would be wonderful to start discussing how this world looks now. I’d love to hear ideas on what provisioner should be used, what features should be started with, and how we can approach making this part of WordPress core.

Props to Zack Tollman for having this conversation with me several times and to Weston Ruter for sparking it again the other day.

v0.8 of Varying Vagrant Vagrants has been pushed

0

v0.8 of Varying Vagrant Vagrants has been pushed

Definitely not as ridiculously long as the v0.7 changelog, but a good month of steady progress.

  • Enable SSH agent forwarding
  • Wrap update/installation procedures with a network status check
  • Enable WP_DEBUG by default
  • Update wp-cli during provisioning
  • Better handling of package status checks
  • Better handling of custom apt sources
  • Add PHPMemcachedAdmin 1.2.2 to repository for memcached stats viewing.
  • Add phpMyAdmin 4.0.3 to repository for database management

If I had to pick favorites, it would be the network status check that is done before installations are attempted and the PHPMemcachedAdmin that we’re now including. If you want to learn more about how data is managed in memcached, this is definitely your tool.

Enjoy!

wcchi-hi-wordpress-meet-vagrant.009

WordCamp Chicago 2013

0

Download Slides: WordCamp Chicago 2013 – “Hi WordPress, Meet Vagrant”

Talk Goals

I want each one of you to leave this talk amped up to use Vagrant for WordPress development.

I know this sounds crazy because I haven’t even told you what Vagrant is all about yet, but I’m really not going to be satisfied until the WordPress community starts to forget what the acronym LAMP even stood for in the first place. As we’re going through this together, I encourage you to imagine ways that 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.

This Post Goals

In the past I’ve used the follow up post with slides to provide a large amount of context for those who came through a bit later. That ends up being a massive dump of information, so I’m going to use this post to highlight a few of the key concepts that I’m hoping everybody took away from the talk. As time progresses, there will be several places on my site to point you to for information on using Vagrant with WordPress.

Vagrant & Magic

“any sufficiently advanced technology is indistinguishable from magic.” – Arthur C. Clark

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 happened without much effort.

“Witchcraft to the ignorant, …. Simple science to the learned” – Leigh Brackett

Over the last 7 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.

This is what we’re going to cover. The transition from magic to approachable advanced technology. I’ll walk through and explain why and how you should start using Vagrant to manage your development environment when creating plugins and themes for WordPress. Together we’ll demystify things a bit so that you’ll immediately want to uninstall XAMPP or MAMP and Vagrant becomes something you’re excited to start using.

30,000 Feet

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 things 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.

Are you ready for what Vagrant is?

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.

Where did the WordPress community come from?

A World of LAMP

For quite a while in the WordPress community, LAMP was the answer. Many people still consider it to be a perfectly fine answer. All you needed was some sort of LAM stack – Linux, Apache, MySQL – with a PHP, Perl, or Python tossed on. Big applications and web sites could be developed this way.

What was great about the LAMP stack is that it became pretty reproducible on our local machines. We saw this earlier with our hand raising exercise. Almost every WordPress developer has probably used some form of XAMPP, MAMP, or WAMP to manage their local environment. This focused sandbox environment goes a long way when building basic WordPress themes or plugins for customers.

That said.

Over time, as a community, we get better at this stuff.

That’s our goal. We don’t strive to do the same, we strive to do better. This is how technology works, and this is what’s required of us to use that technology in better ways.

Breaking Up With MAMP

https://twitter.com/jeremyfelt/statuses/278262418877059072

I got a couple replies to this tweet, one of them asking if I had looked into using Vagrant. I had seen Vagrant mentioned a few months earlier but hadn’t taken the time to grasp what was going on and had kind of dismissed it as something that would be nice to learn, but that wasn’t for me. This time, faced with installing Nginx locally and destroying my beautiful garden, I decided to give it a another chance.

Life changed.

“There’s life before Vagrant, and life after Vagrant. The former ain’t pretty.” – @danielbachhuber

What is Vagrant?

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

These lightweight, reproducible development environments exist on your computer through Virtualization.

Virtualization is “the facility that allows multiple operating systems to simultaneously share x86 processor resources in a safe and efficient manner.”

Virtualbox is software that provides virtualization and 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.”

A great part about both Virtualbox and Vagrant is that installers for each are available for Mac, Windows, and Linux. This means that rather than juggling various MAMP/WAMP/XAMPP/LAMP acronyms, we can all be on the same base platform.

What does this combination let us do?

Allows a guest machine to boot as a sandboxed environment inside a host machine using a combination of a base box and some sort of provisioning.

Getting Started

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

  1. (Install Virtualbox) Download and install Virtualbox
  2. (Install Vagrant) Download and install Vagrant
  3. (vagrant init) 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.
  4. (edit Vagrantfile)
    • In this file we tell the machine what base it should load, what network information it should use, and then how it should be provisioned. For the first go, we’ll leave just a box specified.
  5. (vagrant up) Type `vagrant up`.

This is the magic part. At this point, 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.

As I’m biased to the stuff we do at 10up, I’m going to use an example of shell provisioning taken from our 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 a great number of contributions from the community already, so I really would recommend grabbing this and using it to get your feet wet if not to use as your daily development environment for WordPress projects.

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

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.

Why?

Why should you develop in an environment that matches production?

Over time, as a community, we get better at this stuff.

To make and then meet expectations. There are a variety of issues that can arise between various PHP versions and large differences between how various object caching methods store and expire data. In fact, with a basic LAMP stack using MAMP or XAMPP it may not be entirely obvious how to begin troubleshooting any type of caching issue with WordPress and while APC and Memcached often act the same, it is nice to know that when an issue arises somewhere in your code that you don’t have to question the development environment being used.

During the town hall yesterday, Matt told all of us that he learned to code because of WordPress. I’d venture to guess that quite a few of us also learned to code because of this.

And look at where the community has come since then. We’ve gotten better at UI and UX over the last few years. Accessibility and language translations are both major focuses that have excellent contributors. We have talented business people driving the use of WordPress throughout all types of industries.

Not only does Vagrant help us become better developers by encouraging carelessness and a willingness to experiment with our development environments.

Vagrant allows us to start enlisting devops people into the community. So many problems have been solved in technology by devops already. Think of the server problems that Twitter had when they were growing to scale. Devops solved that. Google and Facebook have both scaled to billions of page views. Devops solved that. An amazing team at Automattic is working constantly to increase the abilities and the stability of the WordPress.com environment. Devops solved that.

Devops can also help to continue WordPress’s growth as a CMS and an application platform. And Vagrant provides a vessel for this to happen.

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 repo.

And 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 covered years ago, you should want a flexible environment that can adapt seamlessly to the technologies that the community must work with today.

Links

Check out the open source Vagrant project at github.com/mitchellh/vagrant.

Check out a provisioned Vagrant setup at github.com/10up/varying-vagrant-vagrants/

Read through the material I’ve posted on Vagrant over the last several months on jeremyfelt.com

And ask questions. Drop an issue on the VVV repo, or send me an email or a tweet @jeremyfelt.