Developing for Drupal with Vagrant and VMs

Many blog posts have outlined the benefits of using VMs (Virtual Machines) for local Drupal development instead of either using native PHP and Apache, or a bundled environment like MAMP, XAMPP, or Acquia Dev Desktop. The advantages of using virtualization (usually managed by Vagrant) are numerous, but in certain cases, you can make a good argument for sticking with the traditional solutions.

If you'd like to take the dive and start using virtualized development environments, or if you're already using Vagrant and VirtualBox or some other VM environment (e.g. VMWare Fusion or Parallels Desktop), how do you optimize local development, and which pre-bundled Drupal development VM will be best for you and your team?

Criteria for the Perfect Local Development Environment

These are the criteria I use when judging solutions for local Drupal development (whether virtualized or traditional):

  • Should be simple and easy to set up
  • Should be fast by default
  • Should be flexible:
    • Should work with multiple providers; VirtualBox is free, but VMWare can be much faster!
    • Should allow configuration of the PHP version.
    • Should work with your preferred development workflow (e.g. drush, makefiles, manual database sync, etc.)
    • Should prevent filesystem friction (e.g. permissions issues, slow file access speeds, etc.)
    • Shouldn't have hardcoded defaults
  • Should be complete:
    • Should work without requiring a bunch of extra plugins or 3rd party tools
    • No extra languages or libraries should be required (why install Ruby gems, npm modules, etc. unless you need them for your particular project?)
  • Should be Free and Open Source
  • Should include all the tools you need, but allow you to disable whatever you don't need (e.g. XHProf, Apache Solr, etc.)
  • Should work on Windows, Mac, and Linux with minimal or no adjustment
  • Should be deployable to production (so your local dev environment matches prod exactly)

A lot of these points may have more or less importance to a particular team or individual developer. If you're a die-hard Mac user and don't ever work with any developers on Windows or Linux, you don't need to worry about Windows support. But some of these points apply to everyone, like being fast, simple, and flexible.

If you're looking for a way to improve team-based Drupal development, all these bullet points apply. If your entire team is going to standardize on something, you should standardize on something that gives everyone the standard layout that's required, but the flexibility to work with each developer's environment and preferred development tools.

Announcing Drupal VM

I built Drupal VM over the past two years for my local Drupal development needs, and continue to improve it so it meets all the above criteria.

Drupal VM is a local development environment that works with a variety of Drupal site development workflows with minimal friction. Whether a site is built via drush makefiles, uses a 'codebase-in-a-git-repo' approach, or is built with install profiles and drush commands, it works with Drupal VM. Drupal VM also includes all the tools I need in my day-to-day development, and even installs helpful software like Apache Solr, Memcache, and MailHog.

Another common scenario I have as a contrib module maintainer and core contributor is my need for a quick, fresh Drupal environment where I can run Drupal 8, 7 or 6 HEAD and hack on core or one of my contrib modules (like Honeypot). Drupal VM is preconfigured to install a fresh copy of Drupal 8 for local hacking, but it's easy to configure it to run whatever Drupal site and configuration you like!

Since Drupal VM has been helpful to other developers, I've made it more flexible, built a simple marketing page (at www.drupalvm.com), and polished up the documentation on the Drupal VM Wiki. I'm continuing to improve Drupal VM as I get time, adding features like:

  • Ability to choose between Nginx and Apache for the webserver.
  • Ability to deploy to DigitalOcean, Linode, or AWS with the same (but security-hardened) configuration as your local environment.
  • Ability to add Varnish or Nginx as a reverse-proxy cache.

Drupal VM has also been a fun project to work on while writing Ansible for DevOps. My work on Drupal VM allows me to flex some Ansible muscle and work on a large number of Ansible Galaxy roles (like geerlingguy.php and geerlingguy.solr) that are used by Drupal VM—in addition to hundreds of other projects not related to Drupal!

A VM for Everyone

Drupal VM is my weapon of choice... but there are many great projects with similar features:

Alternatively, if you know how to use Puppet, Chef, Ansible, or SaltStack, and want to fork and develop your own alternative dev environment, or build one on your own, that's always an option! Especially if you have a highly specialized production environment, it may be best to reflect that environment with a more specialized local development environment.

On Docker and LXC/LXC (Container-based environments)

Before I wrap up, I wanted to also specifically call out some projects like Drocker and the next-generation Drupal.org testbot infrastructure project, DrupalCI, both of which are using Docker containers for local development. Containerized development environments offer many of the same benefits of virtualization, but can be faster to build and rebuild, and easier to maintain.

Container-based infrastructure is likely going to become standard in the next 5-10 years (much like VM-based infrastructure has become standard in the past 5-10 years)—whether with Docker or some other standard format/methodology (a container's just a container!).

Many hosting platforms use a container-everywhere approach, like:

  • Platform.sh
  • Pantheon
  • Google Container Engine
  • Amazon EC2 Container Service

However, I caution that container-based development has it's own complexities, especially in production—especially with more complicated web applications like Drupal. I also caution against blindly running other people's pre-built container images in production; you should build them and manage them on your own (just like I build and manage my own VM images using Packer, e.g. packer-ubuntu-1404).

In Summary

In short, I've been working on Drupal VM for the past couple years, and I've made it flexible enough for the variety of Drupal sites I work on. I hope it's flexible enough for your development needs, and if not, open an issue and I'll see what I can do!

Further reading

drupal
drupal planet
vagrant
virtualbox
virtualization
vmware
development
drupal vm

Comments

Nice list of Drupal vm solutions. I was planning to create a large Google Spreadsheet with such projects with more information about each one.