Vagrant and Puppet for Drupal development
6 min read
History
We here at FunnyMonkey have been using virtualized development environments for several years. Fortunately for us this has all been with VirtualBox, so making the transition to vagrant made perfect sense. Along with this transition we had previously been using a set of shell scripts to configure our environments exactly the same. While this process was certainly adequate and a major improvement upon XAMP/MAMP/etc, it still left a bit to be desired. Vagrant combined with puppet improves the shortcomings in our previous approach.
What is vagrant?
Vagrant bills itself as "Virtualized development made easy." and this is a fairly accurate self-assessment. From our experience vagrant is an improvement upon just a straight virtualbox development environment. So far, in our limited use, vagrant solves several problems that were issues requiring extensive documentation or manual workarounds for each deployment. With vagrant we solve several issues;
- What is our starting point? Vagrant allows pre-defined boxes to be your configurable starting point. These can have all sorts of options and configuration pre-baked.
- How do we handle host specific issues? Specifically how do we handle the myriad of OS and hardware issues?
- How many CPUs or cores should be associated with this virtual environment?
- How much RAM should this virtual machine use?
- How do I get an active routable internet address on this host?
- Are there any other specific workarounds that need to be accounted for?
- How do we ensure the box is configured as our project needs it? Vagrant kicks off either chef, puppet, or even custom shell scripts to handle project specific configuration. The rest of this documentation will be assuming the use of puppet.
What is puppet?
Puppet is a configuration management tool. What that means is that puppet ensures that the system it runs on is configured in exactly the manner in which the puppet configuration defines. In large scale production or cloud computing environments this is absolutely critical as it ensures that each machine is configured identically. In development environments this is valuable for several reasons;
- In deployments requiring special configuration the development environment can be configured precisely the same as the production environment
- Development environments can be unique per client project. Rather than overloading a XAMP/MAMP installation with a sub-directories or virtual host per project each development environment can be standalone.
- The time required to deploy a development environment is a small fixed cost and is quite predictable.
- Development environments can have the exact packages and configuration they need. Does your current project require the latest PHP, how about compass, or ApacheSolr? Using a virtualized environment allows you to pick the best in class OS and package management for your particular project, and allow that configuration to be used by other members of your team just by using the same development platform.
Why should I care?
Reproducability.
Using defined development environments that mimic or are identical to production allow every team member to have meaningful conversations about real issues rather than being mired in OS specific or configuration specific details. That is, it lets development team members focus on the real problems rather than;
- How much memory is PHP configured to use?
- What version of X are you using?
Most importantly it let's us assume that everyone is starting at point A. This means that in terms of a specific project each team member has the same directions to get from point A to point B. We no longer need a completely unscalable set of instructions on first how to get to point A for each team member. Instead we can focus on the needs of our project.
How do I get started?
You can follow the vagrant getting started instructions here. We have put the scripts we have developed on Github; feel free to grab them and fork them. If you follow these steps through "Install Vagrant" you can then clone our git repository from github which contains some bash scripts and a vagrant with puppet configuration designed for Drupal development.
- Install vagrant
- git clone git@github.com:FunnyMonkey/fm-vagrant.git
- cd fm-vagrant
- run ./build.sh This creates the Vagrantfile and nodes.pp
- vagrant up
- start using your virtual environment.
There is additional documentation included in the README on github.
Questions
Why not just pre-define a box for Drupal development and remove puppet?
While you could certainly do this we feel that the best approach is to configure on the fly. This provides several benefits;
- You can have a consistent basic configuration that every project uses. This affords a certain amount of familiarity in ensuring that each project has a similar starting point.
- Each project can have exactly the components it needs rather than every component that every project could need.
- A pre-baked box or configuration is decent in a static environment. Over time security exploits will be discovered and corresponding fixes will be implemented. Occasionally these security fixes will create incompatabilities with a projects' configured features. As such a project needs to grow and evolve in a similar manner to how its parent OS and configuration grows and adjusts.
Why not grab Drupal as part of the install?
While you can certainly do this, puppet will reset any changes that you make if you do not make the changes via the puppet configuration.
What does this workflow look like?
Once you have the basics set up you just clone the vagrant repository for each project, and then 'vagrant up' a new environment.
I prefer to connect over ssh to the virtualbox as that way everything is self contained in the virtual box. You could also setup shared folders that would map to your host OS if that workflow is better for you or your OS & editor combination does not support editing files over ssh. From here your regular workflow should take effect.
As always if you notice any errors, inaccuracies, or ways in which this approach could be improved please chime in.
