Playbooks are Ansible's blueprint to describe what you would like to be done to the hosts using modules. It 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 using the tools.

The playbook is designed to be human readable in the YAML format. We will look at the common syntax and usage in the Ansible architecture section. For now, our focus is to run an example 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 any given playbook, you can contain multiple plays. In this case, we have one play (line 2 - 6). In this play, there can be multiple tasks, and we also just have one task (line 4 - 6) with the name specifying the purpose of the task and the shell module taking an argument of df. The shell module takes 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 will be there with the df command output. Neat, huh?

Noticed that there were actually two tasks executed 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 that can be used later on in the playbook. For example, one of the facts that the setup module gathers is the operating system. The playbook can later on specify to use apt for Debian-based hosts and yum for Red Hat-based hosts to install new packages.

Underneath the hood, there are actually a few things that has happened for tasks such as copy over the Python script, copy the script output to a temporary file, then capture the output and delete 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 the chapter. I purposely chose a server example to be presented here, because they will make more sense as we dive into the networking modules when we need to deviate from them (remember we mentioned 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 is written in Python so once we are more familiar with the framework, we can use Python to extend it.