Flexible Apache configuration for reusable development environments

Here at Four Kitchens we make BIG websites — a lot of them. In the past, keeping up with the development environments for all of these sites added a lot of overhead, which ultimately means more time managing code than writing it. So like good developers we asked ourselves: “how can we make this better, lower maintenance, and reusable?” What we came up with isn’t necessarily anything new, but has completely changed how our internal development process works.

Previously, we had one codebase per project with one user login to the server; for example, on our website redesign we had a “fk” code base with a “fk” user. This is good in principle but quickly becomes problematic as your team grows. We decided a better approach would be to have individual user logins with sandboxed development environments. This solves our user problem but required some thinking and tinkering to make it flexible enough to work with sandboxes.

Before we get started you’ll need a server that you have root level access to with Apache and the following Apache modules installed:

• mod_rewrite
• mod_vhost_alias

To create our sandboxed environments we set up Apache with wildcard virtual document roots. Each developer needed their own sandbox and could have an infinite number of projects they were working on. Our goal was to have domains set up in the form of DEVELOPER.PROJECT.DOMAIN.TLD i.e. elliott.fk.fourkitchens.com.

Here’s an example using virtual document roots that’s derived from our default Apache configuration:

ServerAdmin webmaster@localhost
ServerAlias ..fourkitchens.com

DirectoryIndex index.php

UseCanonicalName Off
VirtualDocumentRoot /home/%-4/www/%-5

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all

# ...

The key pieces of this virtual host are the VirtualDocumentRoot and Directory directives. The %-N values in the VirtualDocumentRoot allow us to construct the file directory on the fly. The % character corresponds to the domain name that was requested. Adding the -N cherry picks a segment from the domain name starting from the end. So %-1 in elliott.fk.fourkitchens.com would return fourkitchens. Alternatively you can cherry pick from the beginning of the array by using %N where in our previous example %2 would return fk. We used %-N rather than %N so we could also support developer site subdomains (i.e. img.elliott.fk.fourkitchens.com) where we know the relative position of domain elements from the end, not the start, of the URL.

What this means to developers is you no longer have to alter Apache settings to host new development sites. One VirtualHost catches them all and adding a new site is as easy as creating a directory that Apache can read. If you’re setting up Drupal sites you’ll need to make one change to your .htaccess file and uncomment the RewriteBase / line. If your site is running in a VirtualDocumentRoot at http://example.com/, uncomment the following line:

RewriteBase /

This system isn’t without its flaws but is a great starting point for flexible, reusable configurations. In future blogs we’ll talk about how this empowers you to automatically provision new development instances and deploy code on staging and live sites using Jenkins. Happy hacking!