Introduction to Ansible Playbooks

In this video we will start using Ansible Playbooks for the first time.

The outcome of this video should be exactly the same as that which we achieved in the Ad Hoc Commands video, only this time we move the procedure from the command line to a reusable, more maintainable file - our playbook.

The format of a playbook is quite straightforward, but strict in terms of spacing and layout.

We always start a playbook with the three dashes: ---, and then the structure of the file differs depending on what your playbook is aiming to achieve.

In this video, as mentioned, we are going to repeat the process we completed via the ansible command. As such, our playbook will look like this:

---
- hosts: local
  tasks: 
    - name: Install NTP
      apt: pkg=ntp state=installed updated_cache=true

I'd encourage you to use a decent text editor - Sublime Text is my personal preference as it highlights spaces and tabs in a way that makes mistakes easier to spot.

Once you have saved the file - in our case, as our-playbook.yml - we are ready to run the ansible-playbook command.

ansible-playbook our-playbook.yml -k -K -s

Again, this is very similar to the ad hoc commands we have already seen, using the same arguments.

This time, we pass in the playbook which contains the target hosts so we don't have to specify which host or hosts to run this command against.

Again, we are asked for our SSH password, which when provided, will proceed with executing the commands as defined in the playbook file.

After a short period, we should get our result output. Assuming you are using a fresh server, as per the video, the first time we run this playbook, NTP should be installed. We can see this from the output, which says that the [Install NTP] task was run, something was changed, and two tasks output as ok.

The two tasks are the gathering of facts (more on this in a future video), and the installation of NTP. That's why we get two ok's.

The changed task is that the status of something on the system changed. In this case, NTP wasn't installed and now it is. Therefore, something on the system changed.

If we immediately re-run the task, we will see that the next time, both tasks completed successfully again (two ok's), but nothing changed. NTP was already installed, so Ansible is clever enough not to attempt to install it again. This makes our tasks idempotent, which simply means we can run them over and over again, without adverse effect to our system. The Ansible docs put it another way:

Modules are idempotent, meaning they will seek to avoid changes to the system unless a change needs to be made. When using Ansible playbooks, these modules can trigger ‘change events’ in the form of notifying ‘handlers’ to run additional tasks.

We can change the playbook to remove the NTP server by doing the following:

---
- hosts: local
  tasks: 
    - name: Remove NTP
      apt: pkg=ntp state=absent update_cache=true

And now when we re-run the command (the same command as before), the NTP service will be removed. Again, the first time through this will have two ok's and one changed outcome. And if we were to re-run the command, the second time through would show two ok's and nothing changed.

This task is nice and straightforward.

As we proceed, you will see that some tasks can become quite involved, and that potentially, can introduce problems. As such, it's a really good idea - especially in our training environment - to take regular snapshots. That way, should something go wrong, rather than having to log on to the server and manually clean up the mess, we can simply roll back to our snapshot, make the necessary changes to our playbook, and then try again.