Configuration management with Ansible

Any Linux distribution will come with a set of administration tools built in. These tools may be user-friendly and helpful, but they are, as a general rule, not aimed at an administrator who has a large number of systems to deal with. Patience with graphical administration tools and text editing tends to run out before the administrator runs out of fingers to count systems on. Local customization scripts can help preserve sanity for a little while, but, especially in this era where virtualized systems pop into and out of existence as a matter of course, there comes a point where it is necessary to overlay some sort of configuration-management tool on top of the distribution running on any given machine.

Your editor recently hit that point and decided that it was time to learn about these newfangled configuration tools. Tools like CFEngine (started in 1993) might be relatively new on the scene, but perhaps one might be able to conclude at this point that they are not going away in the near future. It didn't take much research time to come to a few preliminary conclusions.

One of those would be that there are quite a few of these tools now. Available offerings include Ansible, CFEngine, Chef, Puppet, Salt, Vagrant, and numerous others. These projects are all free software, and they all appear to be at least moderately healthy with significant user bases. Free software is said to be an exercise in scratching one's own itches; it seems that quite a few developers have this particular itch and have found the energy to do some scratching.

One also quickly concludes, however, that a fair amount of the itching driving these projects is financial in nature. It is a rare configuration-management project that doesn't have a company behind it just waiting for the opportunity to provide ancillary services. Ansible offers a dashboard add-on and consulting services; CFEngine has an "Enterprise Edition" with a graphical interface and support options; Chef has centralized configuration storage and, yes, a management console, and so on. Configuration-management tools appear to be almost uniformly open-core offerings with proprietary administrative tools and support services layered on top.

These tools also tend toward a high level of complexity. Many of them require multiple daemons running on each managed system and can be quite intimidating to approach. If one is trying to manage a data center with tens of thousands of nodes serving multiple functions and with its own dedicated hydroelectric plant for power, this complexity may prove to be necessary. It may also be useful if one has outsourced the power bill to a cloud provider and instantiates new systems like raindrops. For those with more modest requirements, though, all that complexity seems like overkill.

Your editor, being one of those with relatively modest requirements, shied away from most of the available configuration-management systems. The expected payback just didn't seem to justify the effort required to get to the first stage of learning (which is, of course, configuring a new system to boot and say "hello, world"). But then Ansible came into view, and it seemed like it might merit a further look.

Ansible

It is worth saying from this outset: your editor is not prepared to say that Ansible is the best solution for any particular use case. It is far too early for any such statement. This article, instead, should be seen as a look at one of a number of potentially interesting tools for configuration management.

Ansible got off on the right foot by making it clear that there is no need to install software on the machines to be managed. There are no daemon processes that run on these systems. Instead, everything is run in a "push" mode via SSH from a central server (or, really, from any system that has the Ansible configuration on it). That makes it easy to get started and to build up to a more complex configuration setup.

On the other hand, this mode of operation almost certainly slows things down. Before it can perform any configuration work on a target system, Ansible must push its own software onto that system and go through a "fact-gathering" phase. A long-running daemon on a target will not need to completely familiarize itself with the state of that target for every update, while Ansible does. For relatively small networks, speed is not a problem. For large, complex configurations it might be.

Ansible works with a declarative configuration in the YAML syntax; this configuration is split into one or more "playbooks." "Declarative" means that the configuration file describes the desired state of the target system, rather than a set of steps for getting into that state. So Ansible configuration blocks say things like "ensure that these packages are installed and current," "there should be an account called 'foo'," or "the 'bar' service should be running."

The advantage of this approach is that Ansible can compare the desired and current states of a system and figure out the minimal amount of work to get the system into the desired state. The tool can be run at any time and it will perform whatever tweaks are required while minimizing unnecessary thrashing on the target system. The downside is that it is not always easy to describe the desired state in this fashion.

As an example, consider this little configuration block:

    - name: Disable password logins
      lineinfile: dest=/etc/ssh/sshd_config
        regexp=^PasswordAuthentication
        line="PasswordAuthentication no"
        state=present
      notify:
        - restart sshd

This is essentially a declaration that the sshd_config file on the target system should have the requisite line disabling password logins. It can take a surprising number of tries to get this kind of thing right; without sufficient care, one might look at the sshd_config file one day and find dozens of PasswordAuthentication lines appended to the end. Not that your editor would make any such mistake, of course.

All of the real work in Ansible is done with "modules" that know how to perform a specific configuration task. The list of modules is extensive. Modules exist to manage file permissions, tweak Apache configurations, perform package management, deal with SSH keys, install Python libraries, manage firewall configurations, deploy software from Git repositories, and more. Much of the task of learning Ansible is an exercise in figuring out which is the right module for any specific job.

As can be seen from the snippet above, Ansible configurations can be on the verbose side. That verbosity can help to make configurations relatively easy to read, but it does get tiresome to type after a while. Some of that verbosity can be mitigated at the cost of using some fairly unintuitive looping constructs. For example:

    - name: install packages
      yum:
        name={{ item }}
        state=latest
      with_items:
        - emacs
        - git
        - nethack

This declaration causes Yum to be employed to install the listed packages on the target system(s). It is easy enough to write and understand once one gets used to it, but it feels awkward; it is an attempt to impose a somewhat imperative, loop-like structure onto a language that is supposed to be declarative. The upcoming Ansible 2.0 release adds conditional structures to deal with failures and such; it will increase the flexibility of the language, but the new structures feel awkward in the same way.

The above snippet highlights one other limitation that is not entirely Ansible's fault. Once one has an abstract description of a system's configuration, one might reasonably want to apply it to systems running different distributions — or, indeed, different operating systems altogether. But those other systems are unlikely to be using Yum, so this item fails. One can get around such issues by using different configurations for different operating systems, but that results in a certain amount of repetition.

The good news is that the 2.0 release includes a "package" module that works with Yum, DNF, Apt, opkg, Portage, and Zypper (and probably others as well). The bad news is that it still seems to have some glitches with some package managers. There is also little to be done about the sad fact that the same program is often packaged under different names on different distributions. Fully distribution-independent configurations are a nice idea, but they are not quite a reality yet.

A complete configuration for a given system type can be long; if one follows the suggested best practices, it will also be split into possibly dozens of files in a deep directory hierarchy. For added fun, half of the files will be called main.yml. This organization provides a lot of flexibility and modularity, but, as one is trying to figure out which main.yml needs to be edited to accomplish a particular task, it's hard not to feel that there should be a better way.

The error diagnostics provided by Ansible are, to put it bluntly, poor. There is, for example, no indication of which file contains a particular problem. The 2.0 update improves this situation considerably; the Ansible developers evidently figured out single-line "foo is not a legal parameter in an Ansible task or handler" failure messages were not helping their world-domination goals.

Needless to say, Ansible has lots of features designed to aid the administration of large networks, including variables and templates, a mechanism for combining configuration combinations into "roles," the ability to update many machines in parallel, and so on. There is a set of modules for interfacing with various cloud providers to perform basic orchestration tasks, and others to deal with OpenStack-based clouds. The modules themselves are written in Python and are relatively easy to create or extend.

Ansible is still not in production use here at LWN; there is more messing around to be done before we can reach that point. But it is clear that tools like Ansible have an important role to play in a world where "the server" is no longer a big box named after a Lord of the Rings character, but is, instead, just one of vast numbers of essentially anonymous appliances. It is not surprising that a lot of energy is going into the development of these tools. After all, system administrators have always been big fans of automation; a variety of free configuration-management tools makes it easy for each of them to scratch that itch in the way they think best.

---

to post comments

    - name: Disable password logins
      lineinfile: dest=/etc/ssh/sshd_config
        regexp=^PasswordAuthentication
        line="PasswordAuthentication no"
        state=present
      notify:
        - restart sshd

    - name: Disable password logins
      lineinfile:
        dest: /etc/ssh/sshd_config
        regexp: ^PasswordAuthentication
        line: PasswordAuthentication no
        state: present
      notify:
      - restart sshd

    - name: install packages
      yum:
        name={{ item }}
        state=latest
      with_items:
        - emacs=text editor
        - git=version control
        - nethack=game

    - name: install packages
      yum:
        name: {{ item }}
        state: latest
      with_items:
        - emacs=text editor
        - git=version control
        - nethack=game