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:

Caching both HTTPS and HTTP Drupal sites behind HAproxy and Varnish

Scenario: you have a Drupal site behind a proxy such as HAproxy, sending traffic to a Varnish backend (which in turn sends to the Nginx or Apache backend).

You want to serve cached pages from Varnish for both HTTP and HTTPS. Perhaps you've tried this and you found that behind HTTPS, your site had no CSS or JS. This is because it's serving a page object that was cached as HTTP, or it's not caching at all, but Drupal is serving the markup with http:// links and your browser won't allow that to be displayed under https:// .

An introduction to Terraform (and a neat way to try Drupal 8)

At Drupalcamp Melbourne 2015, I gave a talk about Terraform and how it can be used to keep the state of your infrastructure in configuration management.

What is Terraform?

People who are familiar with Puppet or Chef and similar config management tools will probably grasp the concept of Terraform.

PHP backdoor shells in Drupal: not always file-based

The other day I was trawling through the overnight OSSEC notifications received at a customer's infrastructure and I came across one such item:

OSSEC HIDS Notification.
2015 Jun 21 17:05:58

Received From: (XXXXXX.example.com)>/var/log/auth.log
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Portion of the log(s):

Jun 21 17:05:57 XXXXXX sudo: pam_unix(sudo:auth): conversation failed


"That's odd", I thought. This server doesn't really get frequent logins let alone use of sudo.

'So, what is it you exactly do?' - Part six, high availability

In this segment of 'what do you do, sysadmin?' I'll cover the area of high availability, building infrastructure that can withstand failure, and preparing for worst case disasters.

Using Ansible to deploy Drupal

Here's an example of an Ansible playbook which deploys Drupal. It's probably not perfect/maybe even 'wrong' in some way, I don't know. I'm teaching myself Ansible in the process :)

It is deceptively simple, but there are some sophisticated components of this approach to Drupal deployment which are characteristic perhaps of my philosophy on deployments more than anything else, and share a lot in common with traditional Capistrano-style deployments. Summed up, they are:

'So, what is it you exactly do?' - Part five, troubleshooting

In the last article of this sysadmin series, I talked about the importance of monitoring as an insight into infrastructure and application behaviour - something that is hard to overstate. But what good is monitoring if you don't understand what it's telling you? That's where troubleshooting comes in.

'So, what is it you exactly do?' - Part four, monitoring

Here's a scenario...

At 4:30AM every Thursday (sysadmin's time), a server's site suddenly spikes in load, because a full backup takes place at such a time, which is not an off-peak time in terms of traffic due to international visitors.

A bunch of users visiting a site on that server receive a flurry of 502 errors trying to load some content - a form of application timeout due to the taxing effect on the CPU related to the backup process.

'So, what is it you exactly do?' - Part three, security

This article is third in a series of long, windy answers to the inevitable 'but what exactly do you do as a sysadmin consultant?' question. I started writing this because it's hard to give a sufficient short answer.