The Easiest Way

Compact Playbook

Roles used in the recommended way keep the playbook very short. It defines only the host group it refers to and the roles it applies to it (Listing 3). Afterward, the playbook can be invoked by:

ansible-playbook -i hosts playbook.yml

<pre>
- hosts: infra
  become: yes
  roles:
    - lmtestrolle
<pre>

The task from this example would result in hello-world being installed on all target systems.

Dynamic Inventory

Critics and supporters alike say that one of Ansible's greatest strengths comes from the compilation of its inventory. The easiest way to build one is to use a good old plain text file in the main Ansible installation folder. However, this does not offer a great deal of flexibility; especially in dynamic environments such as clouds, in which you are soon likely to reach the limits of the approach. Ansible therefore offers a dynamic inventory option, in which ansible or ansible-playbook compiles the inventory file from various sources at runtime.

In particular, setups with a central single source of truth with information about all systems will benefit from this principle. For example, if you use Cobbler for bare-metal deployment, you can use a custom Python script [2] to generate the inventory from the host list of systems stored in Ansible. If you use OpenStack, either as a tool for managing bare-metal systems or for running virtual machines, you can retrieve the list of target instances directly from the OpenStack API with the openstack_inventory script [3].

Connecting Ansible directly to a data center inventory management (DCIM) tool like NetBox is a tad more elegant. A DCIM tool lists the existing servers by definition. Because NetBox in particular contains a completely machine-readable API, establishing a connection is particularly easy. A sample NetBox script [4] for Ansible's dynamic inventory illustrates this functionality.

Infrastructure as Code

If you just write a few Ansible roles for your automation or combine a few ready-made roles off the web, you will get a reasonably clear, but still very powerful, Ansible directory. In the spirit of infrastructure as code, managing the entire Ansible directory in a Git repository offers a number of benefits.

On the one hand, you can automatically establish a single source of truth for the code in use by specifying that the HEAD in this Git directory must always be the currently rolled out production version. On the other hand, managing an Ansible directory in Git makes it easy to work on the directory as a team and track changes.

Ansible playbooks and roles must always be idempotent by definition. If you run Ansible against your systems 10 times, you must end up with a working system 10 times over that has successfully completed the steps anchored in Ansible. If you make a mistake while working with Ansible, you can very easily revise changes and run Ansible again if a Git directory is available. This normally restores the previous state and solves problems caused by a (temporary) misconfiguration.