Round Two

According to Ansible's changelog [1], the name "Ansible" comes from Ursula K. Le Guin's 1966 novel Rocannon's World . Her communicator of the same name operates at greater than the speed of light, without delay, with any place in the universe.

Today's admins are more likely to know Ansible as an orchestration tool and competitor to Puppet, Chef, and Salt. Ansible [2] was acquired by Red Hat in 2015, and although it has generated no major headlines, it has seen some new releases.

A blog on the Ansible site [3] described the new features of the current version, one of which is related to execution speed. The team revised parts of the engine so that it now parses playbook and other YAML files faster. Additionally, Ansible 2.0 offers useful extensions and more than 200 new modules – mainly for OpenStack and CloudStack and Windows.

Ansible is available in free and commercial versions. In contrast to many of its competitors, it does not rely on agents on managed systems, using instead a Python interpreter. Although this arrangement simplifies getting started, admins need to trigger the configuration change themselves.

Most distributions currently still have version 1.9 as the default package. The Ansible website has the latest version 2.0, along with instructions for installing the software on the major operating systems and Linux distributions [4]. Gentoo Linux, which resides on the lab computer, already has the current version as a repository package. All I needed was an entry in the /etc/portage/package.accepted_keywords file for the next update to receive the latest Ansible.

Task Blocks

Task blocks (Figure 1) let administrators bundle related tasks. If Ansible successfully executes a block of this kind, it then triggers other actions. This approach follows the try-except-finally mechanism in Python (or the try-catch-finally construct in Java), Listing 1 shows an example.

01 - hosts: test-hosts
02   tasks:
03   - block:
04     - name: Test Block
05       command: /bin/false
06       tags: notworking
07     - name: Test Block 2
08       command: /bin/true
09       tags: working
10     rescue:
11       - debug: msg="error error error"
12     always:
13       - debug: msg="always always always"

Figure 1: Task blocks are oriented on the Python try-except-finally mechanism.

If an error occurs – and this will always occur in the case of Listing 1 because of the expression /bin/false (line 5) – the instructions in the rescue block apply. Ansible always runs the always block, which might be necessary, for example, to perform cleanup work – which is constantly necessary.

New Execution Strategies

As of version 2.0, you can influence the order in which Ansible handles tasks. Before, the software made this decision on its own. For example, configurations distributed across a series of hosts were grouped in Ansible's hosts file (typically, /etc/ansible/hosts) under a name that the playbook then chose as the target for its actions. To process multiple steps, Ansible always waited for the results for all of the hosts in the group to return before moving on to the next action.

The new strategy keyword hands over more influence on the workflow to the administrator. If you set a value of free, Ansible completes all tasks as quickly as possible, no matter how far along the other hosts in the group are. You don't want to set this value if dependencies could lead to inconsistent states, however.

At this point, you can't forget the serial parameter, which has been around longer. This parameter define how many hosts Ansible targets at the same time, so you can roll out updates within clusters without taking down the whole.

Modules

The 2.0 release announcement also refers to 200 new modules [4], a large number of which relate to CloudStack and OpenStack. Modules let you manage administrative tasks directly from within a playbook (e.g., creating networks, images, etc.).

Version 2.0 also offers a similar set of modules for VMware environments that use vCenter. If you run your cloud on Amazon's Web Services instead of in-house, corresponding AWS modules are available. Ansible 2.0 also has a new Docker connection plugin.

Administrators can use modules not only to roll out individual virtual machines, but also to set up complete virtual data centers, including virtual networks with matching security settings. Because all modules have similar functions and thus introduce abstractions, you can – with a certain amount of skill – manage the hypervisors independently and leave it to Ansible to apply abstract configurations to tangible hypervisors. If you manage Windows machines, you will also appreciate a set of modules for managing Internet Information Server (IIS) and a number of parameters for firewall rules or Windows updates.