What is an Ansible Playbook?

Ansible at its core is a configuration management tool which means it allows us to manage the configurations of our machines. These applications make use of Ansible modules that are developed depending on the endpoint’s connection, interface, and instructions.

Ansible then runs these modules (through regular SSH by default) and removes them after they’re done (if applicable).

Ansible is the most straightforward method for automating everyday IT activities. It’s intended to be simple, consistent, safe, and dependable, with an incredibly short learning curve for administrators, developers, and IT managers.

Ansible playbooks are an essential feature of Ansible and the foundation of every Ansible setup.

Table of Contents:

• What is an Ansible Playbook?
• How do Ansible Playbooks Work?
• How to Build an Ansible Playbook?
• How to use Ansible Playbooks?
• What are the Variables of Ansible Playbooks?
• Example of Ansible Playbooks

Check out this video for more information about Ansible Playbook!

What is an Ansible Playbook?

An Ansible playbook is a file in which users write Ansible code, which is a structured collection of scripts that define the work of a server setup. They define a series of stages in a general IT process or a policy that your remote systems must follow.

Playbooks are collections of one or more plays that are performed in a certain order. A play is an ordered sequence of tasks performed against hosts from your inventory. The task to be done is defined by plays. Each play has a list of hosts to configure and responsibilities to complete. There are no standardized plays; each play must be written by an administrator.

• YAML, a human-readable data processing language, is used in playbooks.

• “YAML” is a sequence acronym that stands for “YAML Isn’t Markup Language.”

How do Ansible Playbooks Work?

Ansible modules carry out tasks. A play may be created by combining one or more Ansible jobs. An Ansible Playbook is made up of two or more plays. Ansible Playbooks are collections of tasks that run automatically against hosts. Your Ansible inventory is made up of groups of hosts.

Each module in an Ansible Playbook is responsible for a certain task. Each module has metadata that indicates when and where a job is performed, as well as which user does it. There are lots of Ansible modules that execute various IT tasks, including:

1. Cloud management

OCI_VCN creates, deletes, or updates virtual cloud networks in Oracle Cloud Infrastructure environments.

2. User management

Selogin maps Linux operating system (OS) users to SELinux users and gitlab_user creates, updates, or deletes GitLab users.

3. Networking

Dozens of modules handle application programming interfaces(APIs); Cisco IOS, NXOS, and IOS XR devices; as well as F5 BIG-IP services.

4. Configuration management

PIP manages Python library dependencies while assemble consolidates configuration files from fragments.

5. Security

Openssh_cert generates an OpenSSH host or user certificates, and ipa_config manages global FreeIPA configuration settings.

How to Build an Ansible Playbook?

Ansible playbooks have the ability to get pretty massive and sophisticated. But whether you’re writing a short and sweet playbook or a massive epic, here’s how you do it.

Every playbook is divided into the following standard sections:

1. Host

The host section specifies the computers on which the playbook will be executed. This data is derived from the Ansible inventory file. As a result, the host section is a list of devices.

2. Variable

The variable section is optional and provides any variables required by the script. If at all, it can be as huge or as little as needed.

3. Tasks

The task section describes the usage of Modules and identifies the tasks that the target machine must do. Every job is given a name, as well as a brief description of what it accomplishes, and is listed when the playbook is executed.

Elevate Your Career with DevOps

Join Our Expert-Led DevOps Training Now!

Explore Program

How to use Ansible Playbooks?

Ansible makes use of the YAML syntax. YAML stands for yet another markup language or YAML ain’t markup language, depending on who you ask (a recursive acronym). YAML file extensions are also varied, but acceptable: (.yaml) or (.yml).

Ansible Playbooks can be used in two ways: through the Command Line Interface(CLI) or through the Red Hat Ansible Automation Platform’s push-button deployments.

• From the CLI: To launch Ansible Playbooks, just use the ansible-playbook command after installing the open-source Ansible project or the Red Hat Ansible Automation Platform.
• From within the platform: The web-based user interface of the Red Hat Ansible Automation Platform offers push-button Ansible Playbook deployments that are utilized as part of bigger tasks (or job templates). These deployments provide extra precautions that are especially beneficial to users who are new to IT automation or who may not have as much expertise working with the CLI.

What are the Variables of Ansible Playbooks?

Ansible utilizes variables to assist users in dealing with system variances, as no two systems are the same. Variable names are made up of letters, digits, and underscores, but they must always start with a letter. Variables also never include blank spaces.

Variables may be defined directly in playbooks by using the “vars:” command. Variables can be anything from proper nouns to ports to web servers or even a specific command.

• For example, you may create a playbook in which you greet individuals with “How’s it going, eh?” by defining a variable called “greeting” with the value “How’s it going, eh?” When the user runs the playbook, the message is shown on the terminals.

Variables are used to store values, and you may build practically any type of variable you require. There are variables for groups and hosts, inventory files, array variables, dictionary variables, and special variables.

Special variables are built-in variables that cannot be changed by the user and are always overridden by Ansible. You may alternatively maintain variables in a separate file and import them as needed with the vars files command.

It is important to note that your playbook does not have to include variables if they are not required. They are completely optional.

Launch Your DevOps Career Today

Access Our Free DevOps Learning Resources

Explore Program

Example of Ansible Playbooks:

Ansible can communicate with a wide range of device types, including cloud-based REST APIs, Linux and Windows systems, networking devices, and much more. This is an example of two Ansible modules that automatically update two different types of servers:

- name: Ansible
    hosts: servers
    become: yes
    become_user: root
    tasks:
      - name: ensure apache is at the latest version
        yum:
          name: httppd
          state: updated version
      - name: ensure apache is running
        service:
          name: httpd
          state: started

This short ansible-playbook example should be enough to have your Apache installation completed and ready. Let’s now have a look at the blocks mentioned above and their purpose.

• Name is used to define the playbook’s name, it purely acts as metadata, i.e. has no impact on the tasks being performed but helps others understand the reason behind the block.

• Hosts are used to define a collection of hosts that are often grouped together as a host group and defined in an inventory file.

• Become is used to tell Ansible, that the below-mentioned task must be performed with higher privileges.

• Become_user is the username we wish to switch to, similar to sudo su – user. If you specify a username after become_user then the task will be executed as that user.

• Tasks a collection of activities to be completed, all tasks would be stated below this

Then we have two jobs with two modules, the first of which is yum and the second of which is service.

The latest variable in the first yum job signifies that the above-mentioned package httpd should be installed if it is not already installed (or) updated to the latest version available if it is already installed. If you do not want it to be updated if it is present, modify the state section of the playbook appropriately as in state: present to make sure it is installed and state: absent in order to remove it.

Conclusion

Ansible believes that you should not require another framework to validate the fundamentals of your system. This is because Ansible is an order-based system that will fail instantly if a host encounters an unhandled error, preventing further setup of that host. This pushes mistakes to the top of the list and displays them in a summary at the conclusion of the Ansible run.

However, considering Ansible is a multi-tier orchestration system, it is quite simple to integrate tests at the conclusion of a playbook run, either via loose tasks or roles. When combined with rolling updates, testing processes can determine whether or not a machine should be returned to a load-balanced pool.

If you’re interested in learning more about Docker, consider delving into our DevOps course.