The Ansible IT automation tool makes it easy to introduce automation into your environment. In this article, I introduce Ansible and its basic capabilities and how to use them, and I discuss which components in the Ansible camp make an admin's life easier. Toward that end, I venture a look at Ansible's future under the current owner Red Hat.

Early Steps

In 2014, the world of automation on Linux was very different from today. I had just started a job in Berlin that involved building an OpenStack platform. Puppet fans set the tone in the company, so the idea was for the OpenStack cloud to be something for the Puppet players, too. However, OpenStack was far removed from its current level of maturity at the time, and the modules offered by the developers were more of a big mess than a solution that could be used in production. What this meant in terms of daily development of the platform soon came to light in an extremely unpleasant way.

The Puppet usage that the OpenStack developers specified was inefficient and slow. Before Puppet even started to change anything on the systems, several minutes could pass. In the worst case, the process ended up producing an error that kicked an entire hour of Puppet runtime into the gutter (Figure 1). Puppet offered little comfort because the OpenStack developers did not have a handle on versioning their modules but allowed the individual modules to reference each other wildly.

Figure 1: Complex suites like Puppet, Chef, and others require so many resources that sometimes even the OOM killer kicks in. © Geoff Williams

Moreover, preparing configurations for services proved to be extremely tedious: Puppet looked to obtain its configuration from the built-in key-value component, Hiera. The developers endeavored to map every configurable parameter from OpenStack in Puppet and thus also in Hiera. Therefore, sooner or later they translated entire OpenStack configuration files from the INI format to YAML for Hiera. The occasionally used term "YAML scoops" was born at that time.

Not only was the Puppet configuration in need of improvement, but its feature set with regard to OpenStack, as well. The procedure "Do this on Host A, then that on Host B, and finally the next on Host C" was impossible to implement with Puppet. However, it was central to OpenStack deployment (e.g., with Galera).

A colleague of mine brought Ansible into play. At that time, it was just two years old and far away from its current feature set. Where Puppet was pretty much a shock, Ansible impressed right from the outset because of its simplicity of use, the way it made nesting unattractive, and the way it more or less self-documented. Instead of a huge YAML bucket, Ansible simply gave you the option of storing a template for configuration with all the desired parameters. Only the host-specific entries needed to be exchanged dynamically (e.g., the IP addresses).

Terminology

As with any automator, Ansible has by now developed a kind of jargon that admins need to know before embarking on the Ansible adventure. Because this article would be difficult to understand without these terms and the knowledge of them, I will go into them here.

The term inventory is of central importance. The inventory captures the target systems on which Ansible executes commands once the admin instructs it to do so with a playbook , which lists the host definitions from the inventory to which the specific playbook refers, as well as the roles to be invoked. A role , in turn, consists of a list of tasks to be processed, as well as configuration files and templates associated with this task, along with handlers (i.e., services that restart after a configuration change or perform other event-driven tasks).

This triple of inventory, playbook, and role is enough to let Ansible do tasks on a specific host – almost: Under the hood, Ansible has modules that take specific steps and are designed to be as granular as possible; the administrator calls them in playbooks. If required, you can also write your own modules, but thanks to Ansible's enormous range of functions out of the box, this is not normally necessary.

Simple SSH Instead of Client-Server

The requirements to get Ansible up and running are simple, and so is the architecture of the solution. Other automators chose client-server protocols and require appropriate services on both the central management server and the target systems. Ansible was designed differently from the beginning: It uses the established and high-performing SSH protocol (Figure 2) to execute commands on other systems.

Figure 2: Ansible relies on SSH in the background and does not need its own agent on the target systems, which scales very well.

This setup inherently has many advantages, but also some disadvantages. Users can use SSH to execute commands on systems, for example, if their own SSH key is stored there and forwarding is working in the SSH agent. Additionally, they must be able to use sudo to assume sys admin privileges on the affected system. To ensure performance, Ansible also uses scp to copy the modules it needs to execute on the target systems beforehand. Whereas Puppet and Chef require the automation server to execute the modules for all target computers, Ansible distributes this task to the systems themselves, which naturally scales far better.