Before we dive into creating playbooks I am going to cover briefly what they are so you can get an understanding of how they fit into the Ansible picture.

Please check out my other articles that cover getting up and running with Ansible.

• Getting Started
• Expanding Playbook Functionality
• Using the Vault

A Playbook represents a hierarchy of “plays” and “tasks” to execute against one or more machines when the playbook is called by Ansible. Each play within a Playbook can target a specific group of machines and have one or more tasks within it. Each task within a play carries out a specific action (i.e. installing a package, running a command etc.) using Ansible “modules”. A full list of available modules can be found here (https://docs.ansible.com/ansible/latest/modules/list_of_all_modules.html).

The order of the Playbook file dictates the order of execution when the Playbook is run by Ansible, running from top to bottom.

The simplest Playbook is one that contains a single play that contains a single task.

Sample Use Case

For this article I am going to cover a basic use case which will be to stand up and configure Apache on a CentOS7 machine. The machine will be a minimal install and be already configured with a user account (called “admin”) that has sudo rights and is configured with my public ssh key (in /home/admin/.ssh/authorized_keys”).

Defining Host Groups

Playbooks are executed against one or more groups. The membership of these groups are contained and managed with either the default Ansible hosts file (/etc/ansible/hosts) or separate inventory files that can be created for further granularity.

In this use case I am going to create a group in the main hosts file and place a client machine within it.

Basic Playbook

I have created a specific directory for hosting my Playbooks (/etc/ansible/playbooks) on my Ansible server.

The most important thing to understand about Playbooks is structure. You cannot use tab spacing within them and everything has to be indented to the correct levels for the file to be executable by Ansible.

To start with I have created an empty file called “basic.yml” and populated it with some starting configuration including:

• hosts – the group of machines the play within the playbook should apply to. This signifies the start of the play.
• tasks – the set of tasks to execute as part of the play
• name – the name of a task
• yum – the Ansible module used to manage application packages with the yum package manager
• name – the package to install
• state – which version of the package to use

Now that we have a Playbook with a single play and task within it we can execute the playbook against one or more machines, in this case my “AppServers” host group using the “ansible-playbook” command.

When I try to execute the Playbook it fails for machine “192.168.110.241” because installing a package on a system requires root permissions. All of our commands are executing as user “admin” using its SSH key which is clearly not “root”.

To successfully install a package on a Linux box you need to either be running as root or have elevated permissions. For this use case we are going to use “sudo” to give the admin account elevated permissions.

Leveraging Sudo

Now that the Playbook runs I need to make it use sudo to allow packages to be installed. The first part to achieve this is to modify the Playbook to include the “become” attribute with a value of “true” or “yes”. “become” tells Ansible to run the commands as the user you specify to become. If you do not specify any user then Ansible assumes you mean the “root” account.

If you want to use an alternative account then “become_user: USERNAME” can be added to the playbook.

Executing the updated Playbook now produces a different error. This time it is less clear what has failed.

To get more information on the failure we can re-run the Playbook adding the verbose switch (-vvv) on to the end to output more logging information to the screen.

Now we can see what the issue is. From the screenshot below you can see the commands are trying to be executed using sudo but there is no password being provided for the “admin” account to use sudo.

To prompt the user for the sudo password I can add “–ask-become-pass” as a command line switch to the Playbook execution as follows:

The basic Playbook now executes as intended, installing the package. This is however only the start. There are many more things we can do.

In the next article we will look at expanding on this use case to add some configuration to the deployed Apache server.