devops

Terraform remote state and errors about AWS_DEFAULT_REGION

This may be obvious to others, but it wasn't to me.

I was setting up Terraform remote state storage (to an s3 bucket) like so:

terraform remote config -backend=s3 \
           -backend-config="bucket=mig5-terraform-state" \
           -backend-config="key=terraform.tfstate"

I kept getting the error on the above:

Failed to read state: Error initializing remote driver 's3': missing 'region' configuration or AWS_DEFAULT_REGION environment variable

This worked, of course:

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:

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.

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:

Using Ansible and Jenkins to check for stale inodes

As part of teaching myself Ansible this week, I've been porting some of my sysadmin toolset into playbooks. I thought I'd share one today that I call 'Stale service check'.

Anyone in operations who does patching on a routine basis knows that a simple 'apt-get upgrade' is rarely enough to apply a security update; Linux uses linked libraries, and frequently when a library is updated, many services that depend on that library are not yet using the new version. OpenSSL is a classic example (remember why you had to 'reboot' to fully clear the Heartbleed vulnerability?)

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

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