OMG Ansible!

03rd June 2018

This is a first impression of Ansible - by an "old-school sysadmin" (my boss called me that once) who's learning infrastructure-as-code for the first time.

What is it?

Ansible is an infrastructure-as-code tool, specifically a configuration-management tool.

The idea of Ansible is to have a description of the state of a system in a text file. Ansible runs through this "code" like a script to:

1. check if the state of the system is correct
2. perform the necessary actions to make it be in that state

It gets a list of machines from an inventory and SSHes into them to automatically sysadmin them the way they should be.

It works using different modules for doing different jobs, for example a mount module for mount-points, a user module for users. The benefit you get from the modules is that they describe state, rather than actions (though it can take action if the state is not as it should be).

And you can split out groups of tasks into re-usable roles, so you can have different jobs that the server does described in different files, and choose the ones you want.

The advantage is that the state of your system is inherently documented to a degree and you can very easily deploy a replica system for testing, or re-deploy it. It prevents that problem you might have when you want to re-deploy a machine on a different OS and find yourself trying to figure out which config values you changed where.

In short, Ansible helps make servers more manageable. Indeed in combination with something like etckeeper or a file-based IDS it might allow one to be pretty certain about the state of a system.

What's it like

The funny thing about Ansible is, it's implementation is actually very messy. This is because UNIX-like systems, and the software people run on them, aren't designed to be managed automatically like this. Ansible requires complicated and specific modules for every task it does. It's almost as silly as Emacs TRAMP mode.

Whoever created Ansible definitely deserves a prize for managing to actually implement this crazy idea. It really is an ambitious project!

Of course, being a messy hack[1], Ansible can't always live up to it's promises.

As an example: when I wrote my first Ansible playbook, I found that there's no module for the Fossil VCS. Therefore, I had to fall-back to using the "command" module, having it run a "fossil open" command if a file that that command creates does not exist. The problem is that if I now change my Ansible playbook to checkout a different branch, and re-run it on the server, it won't notice that the wrong branch is checked out!

Also, it doesn't provide enough abstraction to paper over the difference between different distributions. It's not like "configure this Nginx setting to this value", it's more like "apply this patch to this file".

Do I like it?

While Ansible seems to me like a hack, this does not prevent it from being a very useful tool. It has big advantages over just documentation, or writing a shell script to set everything up.

As an example of how extremely useful it can be, I can deploy test servers for developing Taskenizer in 3 minutes. It used to take an hour!

It's better than just keeping server images and cloning them, because it just configures the parts of the system that are relevant to what's being deployed, making it easy to adapt it to a different OS for example. Also you have a record of what's actually been configured rather than just a blob image.

Over-all, I think it's a great hack and I'm excited to use it more!

[1] hack in this context means a creative or messy solution to a problem