Playbooks are Ansible's blueprint to describe what you would like to do to the hosts using modules. This is where we will be spending the majority of our time as operators when working with Ansible. If you are building a tree house, the playbook will be your manual, the modules will be your tools, while the inventory will be the components that you will be working on when using the tools.

The playbook is designed to be human readable, and is in YAML format. We will look at the common syntax used in the Ansible architecture section. For now, our focus is to run an example playbook to get the look and feel of Ansible.

Let's look at this simple 6-line playbook, df_playbook.yml:

---
- hosts: 192.168.199.170

  tasks:
    - name: check disk usage
      shell: df > df_temp.txt

In a playbook, there can be one or more plays. In this case, we have one play (lines two to six). In any play, we can have one or more tasks. In our example play, we have just one task (lines four to six). The name field specifies the purpose of the task in a human readable format and the shell module was used. The module takes one argument of df. The shell module reads in the command in the argument and executes it on the remote host. In this case, we execute the df command to check the disk usage and copy the output to a file named df_temp.txt.

We can execute the playbook via the following code:

$ ansible-playbook -i hosts df_playbook.yml
PLAY [192.168.199.170] *********************************************************

TASK [setup] *******************************************************************
ok: [192.168.199.170]

TASK [check disk usage] ************************************************
changed: [192.168.199.170]

PLAY RECAP *********************************************************************
192.168.199.170 : ok=2 changed=1 unreachable=0 failed=0

If you log into the managed host (192.168.199.170, for me), you will see that the df_temp.txt file contains the output of the df command. Neat, huh?

You may have noticed that there were actually two tasks executed in our output, even though we only specified one task in the playbook; the setup module is automatically added by default. It is executed by Ansible to gather information about the remote host, which can be used later on in the playbook. For example, one of the facts that the setup module gathers is the operating system. What is the purpose of gathering facts about the remote target? You can use this information as a conditional for additional tasks in the same playbook. For example, the playbook can contain additional tasks to install packages. It can do this specifically to use apt for Debian-based hosts and yum for Red Hat-based hosts, based on the operation system facts that were gathered in the setup module.

Underneath the hood, there are actually a few things that have happened for our simple task. The control node copies the Python module to the remote host, executes the module, copies the module output to a temporary file, then captures the output and deletes the temporary file. For now, we can probably safely ignore these underlying details until we need them.

It is important that we fully understand the simple process that we have just gone through because we will be referring back to these elements later in this chapter. I purposely chose a server example to be presented here, because this will make more sense as we dive into the networking modules when we need to deviate from them (remember that we mentioned the Python interpreter is most likely not on the network gear).

Congratulations on executing your first Ansible playbook! We will look more into the Ansible architecture, but for now let's take a look at why Ansible is a good fit for network management. Remember that Ansible modules are written in Python? That is one advantage for a Pythonic network engineer, right?