Ansible Playbook

Learn about Ansible playbooks in this article by Mohamed Alibi, a Linux system administrator with a specialization in a mass virtual machine and container provisioning and infrastructure administration for medium-sized distributed bioinformatics training facilities.

Ansible playbooks, to demonstrate how to write Ansible play scripts
Now things are starting to get interesting. Using Ansible playbooks, you’ll be able to achieve configuration management, orchestration, provisioning, and deployment. Playbook scripting uses the Ansiblead-hoc commands in a more organized way, similar to the way in which shell scripting arranges shell commands to execute a task on a system, but more advanced than that. Ansible playbooks can set up and configure complex environments on bare metal, virtually, or on the cloud. It can sequence multi-tier machine roll-outs; apply systems, devices, and application patches and fixes; gather data from hosts or monitoring services; and act accordingly to send immediate actions to servers, network devices, and load balancers. All of these tasks can be delegated to other servers.

Playbooks are coded in a YAML data serialization format. This is human-readable formatting, allowing the developer an easier sharing of their code and better organization as part of team projects. YAML is a very simple language compared to a traditional coding/scripting language.

Playbooks cannot do much on their own without their Ansible modules, which you can either get from Ansible Galaxy or build yourself. A playbook script runs multipleplays. Each one executes a number oftasks, which are composed of a number of modules on selected hosts from the Ansible inventory or from an external inventory if this option is selected. These modules apply certain configuration changes, updates, or fixes to the selected hosts, depending on the nature of the module. A simple playbook running one play with one module to update the package manager cache is shown as follows:

nano ./playbook/apt_cache.yml

Then, fill it in with the following code:

---
- name: playbook to update Debian Linux package cache
hosts: servers
tasks:
  - name: use apt to update its cache
become: yes
apt:
update_cache: yes

YAML requires a very strict file structure when writing its files. Well-aligned action parameters are very important for the success of the playbook file. Save the file and then run the ansible-playbook command as follows:

ansible-playbook playbooks/apt-cache.yml

The following output from the playbook's execution shows if the playbook has made a change to the hosts:

As you can see, a task called gathering facts has been executed within your simple playbook. This is a task that runs the module setup, which collects all of the useful information about the host or hosts in question.

When not needed, disabling the gathering facts task can increase the performance of your playbooks. This can be done by adding gather_facts: False when defining a play.

Now, break down the structure of a playbook script. First, explain the name option. This is an optional parameter, but it is highly recommended. When a simple and meaningful sentence is written as input to the name option, it helps provide a useful description of the play for improved user communication. It is also helpful when running the playbook, in order to see which plays have finished and which are still processing. A playbook output without the use of the name option looks as follows:

---
- hosts: servers
gather_facts: False
tasks:
  - apt:
update_cache: yes
become: yes

When executing the preceding playbook, the output should look as follows:

You then have the hosts parameter or line. This is used to point to the inventory that the play should be run on, either to specify a certain group or host, or both of these combined. At the same level within the playbook, you can fill in other parameters underneath it. Those parameters can be host or group variables, usedto enforce the parameters that are configured in their inventory files. These variables can be play-specified when you define them underneath the line hosts:

---
- name: playbook to update Debian Linux package cache
hosts: servers
remote_user: setup
become: yes
tasks:

They can also be task-specific when you define them within the task:

---
- name: playbook to update Debian Linux package cache
hosts: servers
tasks:
  - name: use apt to update its cache
apt:
update_cache: yes
become: yes
become_user: setup

Then move to the tasks list, which is basically a list module to be executed in a series. Similarly, to a playbook, each task can be named using the name: parameter. This is highly recommended for both documentation and to follow upon the status of tasks:

tasks:
   - name: use apt to update its cache
apt: update_cache=yes

If a task fails, the playbook execution stops with the failure. To bypass this when running a non-critical task, you can always add the ignore_errors: True parameter:

tasks:
   - name: use apt to update its cache
apt:
update_cache: yes
ignore_errors: True

As you have seen from the two previous examples, each task's action line can be used in two different ways: either broken down or in one line. You can choose which to use based on your needs.

Finally, handlers are a major factor in making playbooks independent and automated, with less interaction for the user. They have the capacity to recognize changes and act accordingly. They are a way of controlling the system's behaviors and running actions that respond to the needs of those behaviors:

tasks:
  - name: use apt to update its cache
apt:
update_cache: yes
become: yes
notify: pkg_installable

handlers:
  - name: pkg_installable
apt:
name: htop
state: latest
become: yes

When executing the preceding playbook, the output should look as follows:

Handlers can also be placed before the tasks in listen mode to enable action execution whenever they are triggered by multiple tasks.

Advanced Ansible playbook scripting includes conditional and loop statements to give the developer various logic and patterns to play within their playbooks.For example, the when parameter is a way of implementing task control with conditions. Consider the following example, which only runs application updates when it is running on the right family of Linux:

tasks:
  - name: use apt to update all apps for Debian family
apt:
name: "*"
state: latest
update_cache: yes
become: yes
when: ansible_os_family == "Debian"

  - name: use yum to update all apps for Red Hat family
yum:
name: '*'
state: latest
become: yes
when: ansible_os_family == "Red Hat"

The when parameter condition is not limited to values collected from the host system but also from the task's execution status, which can be one of the following:
• The result has failed
• The result has succeeded
• The result has been skipped

There are various other ways to use playbook conditions. The loop statement can also be used. For this, use the loop parameter. In some cases, when you want to apply an action on multiple entries, use the vars: parameter, as shown in the following example:

tasks:
  - name: use apt to install multiple apps
apt:
name: '{{ app }}'
state: latest
update_cache: yes
vars:
app:
        - htop
        - mc
        - nload
become: yes

This can also be done using the loop parameter:

tasks:
  - name: use apt to install multiple apps
apt:
name: '{{ item }}'
state: latest
update_cache: yes
loop:
        - htop
        - mc
        - nload
become: yes

This article is only the tip of the iceberg of Ansible playbooks. There are many more advanced customizations and parameters. Ansible is well-known for its neat and well-maintained documentation, so it is recommended you have a look at this for more information.

If you found this article interesting, you can explore Ansible Quick Start Guide to configure Ansible and start coding YAML playbooks using the appropriate modules. Ansible Quick Start Guide is the easiest way to learn how to use Ansible as an orchestrator and a Configuration Management tool. With this book, you will learn how to control and monitor computer and network infrastructures of any size,physical or virtual.