Playbooks

Ansible playbooks

Automating tasks in Ansible requires a set of instructions or “plays.” You must provide Ansible with instructions on what actions to perform on the resources it manages. You do that with playbooks. A playbook is a list of tasks that run in order from top to bottom.

Think of a playbook as a sports coach’s playbook. A coach has a list of plays that they recommend their team take to win the game. Ansible intends to “win the game” with its sets of plays in its playbook to create or modify resources.

Each “play” in a playbook is called a task. Each task is a specific action Ansible takes on the resource it’s controlling. For example, a task could be creating an Azure storage account, changing the password on a user account, creating a Docker container, or any other number of actions. Think of a task similar to a programming language function; it does one “thing.”

Each playbook starts off with the PLAY keyword. The PLAY keyword specifies on what resource the code will run. This resource could be the Ansible server itself or on a target server it’s managing.

The second keyword is TASK where you see [Gathering Facts]. Gathering facts is Ansible retrieving metadata about the system. Facts are used if a playbook needs any kind of metadata about a target resource. For example, if Ansible was changing the size of a virtual machine in Azure, it would need to know the existing size prior to knowing if the size requested is the same, bigger, or smaller. The TASK tells you what action Ansible took.

The final section of a playbook is the PLAY RECAP. The PLAY RECAP provides the playbook activity history of a particular run. There are five statuses in the recap.

• ok: Below, you’ll see ok=2. This means that two tasks checked the state of the resource and found no changes needed to be made.
• changed: You’ll also see below changed=1. The changed attribute increments if any task in the playbook made a change on the target resource.
• unreachable: This status will increment for each resource it was unable to connect to.
• failed: This status increments when Ansible is unable to perform the specified action from the playbook on the target server.
• skipped: This status increments if a particular task in the playbook is set to skip. There is a great explanation on StackOverflow, which you can find here.
• rescued: This status is similar to error handling. You can have an output stating that an error occurred and perhaps where/how it can be fixed.