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.


'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.



Subscribe to RSS - drupal