Studying the anatomy of a Ansible Playbook

Studying the anatomy of a Ansible Playbook

Playbooks can have a list of remote hosts, user variables, tasks, handlers, and so on. You can also override most of the configuration settings through a playbook. Let's start looking at the anatomy of a playbook.

The purpose of the playbook we are going to consider now, is to ensure that the httpd package is installed and the service is enabled and started. This is the content of the setup_apache.yaml file:

--- 
- hosts: all 
  remote_user: testuser
  tasks: 
  - name: Ensure the HTTPd package is installed 
    yum: 
      name: httpd 
      state: present 
      become: True 
  - name: Ensure the HTTPd service is enabled and running 
    service: 
      name: httpd 
      state: started 
      enabled: True 
    become: True 
The setup_apache.yaml file is an example of a playbook. The file is comprised of three main parts, as follows:

hosts: This lists the host or host group against which we want to run the task. The hosts field is mandatory and every playbook should have it. It tells Ansible on which hosts to run the listed tasks. When provided with a host group, Ansible will take the host group from the playbook and try look for it in an inventory file . If there is no match, Ansible will skip all the tasks for that host group. The --list-hosts option along with the playbook (ansible-playbook <playbook> --list-hosts) will tell you exactly which hosts the playbook will run against.
remote_user: This is one of the configuration parameters of Ansible (consider, for example, testuser -remote_user) that tells Ansible to use a particular user (in this case, testuser) while logging into the system.
tasks: Finally, we come to tasks. All playbooks should contain tasks. Tasks are a list of actions you want to perform. A tasks field contains the name of the task, a module that should be executed, and arguments that are required for the module. Let's look at the single task that is listed in the playbook, as shown in the preceding snippet of code:
Note
All examples in the book would be executed on CentOS, but the same set of examples with a few changes would work on other distributions as well.

In the preceding case, there are two tasks. The name parameter represents what the task is doing and is present mainly to improve readability, as we'll see during the playbook run. The name parameter is optional. The modules, yum and service, have their own set of parameters. Almost all modules have the name parameter (there are exceptions such as the debug module), which indicates what component the actions are performed on. Let's look at the other parameters:

In the yum module's case, the state parameter has the latest value and it indicates that the httpd latest package should be installed. The command to execute more or less translates to yum install httpd.
In the service module's scenario, the state parameter with the started value indicates that the httpd service should be started, and it roughly translates to /etc/init.d/httpd start. In this module we also have the "enabled" parameter that defines whether the service should start at boot or not.

True parameter represents the fact that the tasks should be executed with sudo access. If the sudo user's file does not allow the user to run the particular command, then the playbook will fail when it is run.

Note
Why there is no package module that figures out the architecture internally and runs the yum, apt, or any other package options depending on the architecture of the system. Ansible populates the package manager value into a variable named ansible_pkg_manager.

In general, we need to remember that the number of packages that have a common name across different operating systems is a small subset of the number of packages that are actually present. For example, the httpd package is called httpd in Red Hat systems and apache2 in Debian-based systems. We also need to remember that every package manager has its own set of options that make it powerful; as a result, it makes more sense to use explicit package manager names so that the full set of options are available to the end user writing the playbook.