Connections and Inventory

Ansible is typically used to connect to one or more remote machines via Secure Shell (SSH) and bring them into a desired state. The connection method is pluggable. Other methods include local, which simply invokes the commands on the local machine instead, and docker, which connects through the Docker daemon to configure a running container. Ansible calls these remote machines hosts.

See the introduction to inventory files ² for more information.

Let’s break the command line down into its components. -i myinventory tells Ansible to use the myinventory file as inventory. web tells Ansible which hosts to work on. It can be a group, as in this example, a single host, or several such things, separated by a colon. For example, www01.example.com:database would select one of the web servers and all the database servers.

Finally, -m ping tells Ansible which module to execute. ping is probably the simplest module. It just sends the response "pong" without conducting any changes on the remote machine, and it is mostly used for debugging the inventory file and credentials.

These commands run in parallel on the different hosts, so the order in which the responses are printed can vary. If a problem occurs when connecting to a host, add the option -vvvv to the command line, to get more output, including any error messages from SSH .

Ansible implicitly gives you the group all, which—you guessed it—contains all the hosts configured in the inventory file.

Modules

Ansible comes with a wealth of built-in modules and an ecosystem of third-party modules as well. Most modules are idempotent, which means that repeated execution with the same arguments conducts no changes after the first run. For example, instead of instructing Ansible to create a directory, you instruct it to ensure the directory exists. Running such an instruction the first time creates the directory, and running it the second time does nothing, while still reporting success.

Here, I want to present just a few commonly used modules.

The shell Module

This is fairly generic, but it is also an option of last resort. If there is a more specific module for the task at hand, you should prefer the more specific module. For example, you could ensure that system users exist using the shell module , but the more specialized user module ⁴ is much easier to use for that and likely does a better job than an improvised shell script.

The copy Module

The template Module

template ⁶ mostly works like copy, but it interprets the source file as a Jinja2 template,⁷ before transferring it to the remote host. This is commonly used to create configuration files and incorporate information from variables (more on that later).

More on playbooks later, but what you can see is that this defines a variable team, sets it to the value Slackers, and the template interpolates this variable.

The file Module

The apt Module

On Debian and derived distributions, such as Ubuntu, installing and removing packages is generally done with package managers from the apt family, such as apt-get, aptitude, and, in newer versions, the apt binary directly.

Here, the screen package was already installed, so the module didn’t change the state of the system.

Separate modules are available for managing apt-keys ¹⁰ with which repositories are cryptographically verified and for managing the repositories themselves.¹¹

The yum and zypper Modules

For RPM-based Linux distributions, the yum ¹² and zypper modules ¹³ (at the time of writing, in preview state) are available. They manage package installation via the package managers of the same name.

The package Module

The package module ¹⁴ uses whatever package manager it detects. It is, thus, more generic than the apt and yum modules but supports far fewer features. For example, in the case of apt, it does not provide any control over whether to run apt-get update before doing anything else.

Application-Specific Modules

The modules presented so far are fairly close to the system, but there are also modules for achieving common application-specific tasks. Examples include dealing with databases,¹⁵ network-related things such as proxies,¹⁶ version control systems,¹⁷ clustering solutions such as Kubernetes,¹⁸ and so on.

Playbooks

Playbooks can contain multiple calls to modules in a defined order and limit their execution to individual hosts or group of hosts. They are written in the YAML file format¹⁹, a data serialization file format that is optimized for human readability.

Then it sets the variable go_server to a string, here the hostname where a GoCD server runs.

Playbooks are invoked with the ansible-playbook command, for example, ansible-playbook -i inventory go-agent.yml.

Variables

A third, very flexible way is to use the group_vars feature. For each group that a host is in, Ansible looks for a file group_vars/thegroup.yml and for files matching group_vars/thegroup/*.yml. A host can be in several groups at once, which gives you extra flexibility.

and put environment-specific variables in group_vars/test.yml and group_vars/prod.yml and web server–specific variables in group_vars/web.yml, etc.

The keys that the test group vars file didn’t touch, for example, myapp.db.username, are inherited from the file all.yml.

Roles

Roles are a way to encapsulate parts of a playbook into a reusable component. Let’s consider a real-world example that leads to a simple role definition.

But this requires you to supply the package_version variable whenever you run the playbook. This will not be practical when you’re not running a deployment of a freshly built software, but instead you configure a new machine and have to install several software packages, each with its own playbook.

If you include several such playbooks in one and run them on the same host, you’ll likely notice that it spends most of its time running apt-get update for each included playbook.

As you can see, the code base for sensibly installing a package has grown a bit, and it’s time to factor it out into a role .

pre_tasks and tasks are optional. A playbook consisting only of roles being included is just fine.

Ansible has many more features, such as handlers, that allow you to restart services only once after any changes, dynamic inventories for more flexible server landscapes, Vault for encrypting variables,²⁷ and a rich ecosystem of existing roles for managing common applications and middleware.

For more about Ansible, I highly recommend the excellent book Up and Running, 2nd ed., by Lorin Hochstein (O’Reilly Media, 2017).