In My Toolbox: Ansible

I’ve recently put my hands on a powerful tool: Ansible, the secret weapon that can greatly simplify a developer’s life.

What is Ansible?

It is a tool for Linux automation. It is heralded as a serious contender for Puppet or Chef but its capabilities go well beyond server configuration and/or DevOps. Its special characteristics are:

• easy to use and understand: just .ini files, YAML and Python
• well integrated with Linux: works over SSH, no daemons necessary
• follows a common-sense philosophy: idempotency, aiming towards a prescribed goal
• versatility: nice programmability and great combinatorial power

The last two qualities make Ansible a tool as valuable for a development team as it is for an admin/DevOps team.

To Build or Not To Build …

It is well known how hard is to design a good build system. I would dare say that, for the Java world, producing a good configuration system is even harder. But there is hope: a good build system combined with the power of Ansible makes life easy again.

Configuration … what?

Distributed systems in general, and Java distributed systems in particular, use configurations. Lots of them. It is a necessity, if we want to keep our distributed systems flexible.

But configurations are costly to manage. There are lots of duplications: tens of services may have configuration elements like my_secret_port=35400 repeated over and over again. Should a change occur, it becomes a burden to propagate on more than a handful of services or servers.

Gradle + Ansible

Here is where the combined power of two great platforms, Gradle and Ansible, comes to the rescue:

1. The product does not (primarily) store information in config files; it stores them within a dedicated set of text files listing the assets of the system
2. The build system, by the power of Gradle, generates the config files in the right place. Duplication (virtually) eliminated!
3. The build system, by the power of Gradle, generates the playbooks (recipes) that Ansible will use. Repetitive manual work (virtually) eliminated!
4. The deployment system, by the power of Ansible, deploys the modules by running the playbooks generated by Gradle onto the nodes that come from the asset files mentioned above

Easy, safe and sound.

Templates, maybe

The generation of the Ansible playbooks and Java config files may come directly via Gradle (some plug-in development in order) or, much easier and safer, via a template-ing system like Apache FreeMarker. But, about that, I will write in a future article.