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"

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.

Smaller Chunks

Ansible previously integrated files related to specific tasks (include directives) during parsing, similar to the C preprocessor, and the parser often discovered inconsistencies.

The new 2.0 version only parses the files when Ansible processes them, which can lead to problems with loops that are intended to run against all interfaces. Ansible cannot know in advance what tasks are waiting in a yet-to-be-evaluated include file. The developers will be looking to solve this problem, which also affects tags, in a release in the near future.

The delegate_facts flag was recently introduced to supplement the delegate_to command, which makes it possible to import information from another host (e.g., when the administrator on host A needs the IP address of host B for a configuration setting). Without the new flag, this data ends up in the information of the host being processed. If you were to set the delegate_to flag to True, you would instead access hostvars['B'], which would not otherwise receive this data.

Finally, Ansible also looks for parameters in external files, which previously meant CSV files; however, version 2.0 also looks at INI files.

These files typically consist of sections in square brackets and keyword/value pairs. For the INI file in Listing 2, a call to

{{ lookup('ini', 'key section=test file=test.ini') }}

returns the value string. Property files written in Java can also be used in this way. Although they do not include sections, the call simply uses type=properties instead of section=test.

01 [foo]
02 bar=1
03
04 [test]
05 key=value

Incompatibilities

The complete release notes [5] refer to many "API changes." Unfortunately, the developers do not relate in detail what exactly these changes do, other than a section about escaping with the use of backslashes, which removes the need for quadruple backslashes.

At another point, you will find references to APIs for callback, connection, cache, and lookup plugins.

In the brief test for this article, I noticed that a Junos module I frequently use to configure Juniper devices failed when faced with the Junos version number (Figure 2). It worked perfectly with version 1.9.4 on the same device; therefore, you are advised to take all of your playbooks for a test run before migrating.

Conclusions

Ansible 2.0 comes with a host of new modules – in particular designed for use in cloud environments – that could make the admin's life much easier. Beyond this, the anticipated speed gains and the ability to determine when Ansible will process what host from a group in the playbook are meaningful improvements.

Admins who already use Ansible are advised to test their playbooks thoroughly (as well as any new modules they have installed) before upgrading. Because of the sparsely documented API changes, some incompatibilities can be expected.