Ansible

Fifteen years ago when I first started “making websites”, it was pretty basic. You’d make a change and FTP the file up to the server. And that’s assuming you weren’t editing files live on the server to begin with, overwriting any and all changes from anyone else who happened to be doing the same (sorry Andy). Since then things have got better.

It started with SVN, and now git. Everything goes through a version control system. No more copy-v4 folders lying around. Features live in branches and master lives on the server(s). In fact, for the past five years I’ve been using Beanstalk to manage all my repos and also handle all of the deployments.

This predates the big rise in deployment tools. Beanstalk was as simple as it is elegant. You make an environment, you add your servers, you deploy. And really we haven’t changed much since then. But as we’ve grown and started needing more servers and more versions we needed better control.

It used to be you would use cPanel (shudder) to make a host, connect over FTP and dump the files. Then as we grew you’d spin up a box, SSH in, set it all up with all the tweaks, and SFTP the files over. Over time that “set it all up and tweak” task grew larger and larger. Load balancers suddenly needed nginx pool settings. Varnish had it’s VCL. Sometimes each box would serve a particular role, other times we’d have one or two apps running alongside. We needed a way to manage it all.

Enter Ansible.

Ansible’s simple really. It SSHs into one or more servers, runs some commands and that’s it. Of course there’s some stuff going on around the edges. It can load dynamic instances from cloud providers, and generate host files from templates etc. But for the most part it takes what we used to do and automates it.

I’d been looking for a tool like this for a while. I didn’t like the models behind Chef and Puppet. Whenever looking for a new piece of software I always try and find something that would match how I would have designed it, and Ansible with it’s agent-less idempotent controller was perfect. (It didn’t hurt it’s got a name with a sci-fi pedigree.)

It’s fairly simple to get up and running. The core modules cover off 90% of what you’d normally want. Make tasks to install varnish, edit the default, copy over the VCL and restart. Done. You can stick the playbook (a makefile for servers in effect) in your repo and now any other dev can spin up a machine as and when they need.

There are a few annoyances. On Mac, Python isn’t the easiest thing. I ended up hacking at the system install so I could upgrade six. And while you can have tasks (do this one job) and roles (set up this server type) there’s nothing in between for larger, re-usable components (set up nginx and some hosts).

Anyway, it’s pretty darn cool. The next thing to do now is move more of the configuration out of the code so we can spin up boxes based on feature branches ad-hoc. That and atomic deployments.