Deploying and managing Autoscaled Drupal applications at AWS with Terraform, Packer and Fabric

As part of a prototype/experiment for a customer, I decided to 'eat my own dogfood' and put this site onto an autoscale cluster at AWS.

In doing so, I wanted to manage my infrastructure using Terraform (a configuration management tool). In addition, since the use of autoscale requires using a base image (AMI) capable of hosting the site, I wanted to build the AMI using Packer. Furthermore, I wanted to use Puppet to speed up that configuration of the AMI built by Packer.

'Nice to have' goals

I had a few other goals also in mind:


'So, what is it you exactly do?' - Part two, config management

Continuing on from Part One, where I discuss the far-ranging benefits of continuous deployment, today I'll cover off another large part of the 'what do I do as a sysadmin' question: that being, config management.


Video: Continuous Integration & Jenkins deployment, DC Toulouse 2011

Way back in November 2011, I did an unusual thing: I co-presented a talk about Drupal and Continuous Integration/Deployment at DrupalCamp Toulouse, except that I was Skyped in from my home town of Melbourne, Australia :)

The talk is actually mainly presented by Greg Harvey of Code Enigma, one of my clients, and I just provide - well, I don't know, comic relief with my Australian accent? :)


Enforcing apt-get update prior to any packages installing via Puppet

I've been having weird, inconsistent bugs occur when running Puppet especially on new systems (where it's more obvious).

Specifically: I've seen cases where a manifest Notifies the apt-get update Exec to refresh the apt database, and suddenly the next series of package installs have failed with 'could not find package'.


Testing puppet with Jenkins before deploying

During a rather boring conference a few weeks back, I decided to convert my own infrastructure from 'standalone puppet' (that is, a set of standalone puppet manifests that were executed by a basic shell script on each server I managed) to the 'client -> server' or 'puppetmaster' model (whereby a central puppet daemon controls the manifests, and servers connect to it for updates as 'clients'.)

You can read more about the different models here.


One-touch provisioning and auto-monitoring of new servers

I've recently been doing some very innovative work for the very clever gents at Code Enigma, where I've been working on some interesting projects:

1. an automated 'zero-touch' dev/stage/live deployment system for their enterprise Drupal applications (developers no longer need to ssh in to servers to do deployments)

2. automatic 'one-touch' provisioning and configuration of new hosting cloud services.

(More on the dev/stage/live zero-touch deployment soon :) )


Subscribe to RSS - puppet