automation

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

'So, what is it you exactly do?' - Part one, continuous deployment

I hear this question a lot - both from non-technical folk, as well as agencies who know they are 'missing something' in their approach to deploying, securing and scaling applications, but aren't sure if a sysadmin will solve it. 'What is it that you (a sysadmin) actually does (e.g the day-to-day, or in general)?'

Trying to automate the initial OSSEC installation steps

I haven't got around to packaging OSSEC for Debian yet - mainly because I haven't decided how to handle the fact that OSSEC uses a server->agent model that depends on the generation/importing of unique keys for communication (not unlike Puppet with SSL certificates), from an automation/Puppet perspective.

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 :) )