Simplifying Ansible Playbooks with Roles

Overview

After completion of this blog, you should be able to work with a role in a playbook’s project directory and run it as part of one of the plays in the playbook.

As you work more on the playbook, you will probably discover that you have many opportunities to reuse code from the playbook that is already written. Perhaps a play to configure a web server with different versions or configure MySQL database for different usernames, passwords, and hostnames.

Introduction

Ansible Roles make it easier to reuse Ansible code. You can package in a directory structure containing all the tasks, variables, files, templates, and other resources needed to configure software, applications, etc. Copy that role from project to project simply by copying the directory. You can then simply call that role from a play to execute it.

Roles are a supplemental playbook feature that can be utilized on its own. Under no circumstances can the role be performed directly. Top-level playbooks serve as a link between the hosts in the user’s inventory file and the responsibilities that should be applicable to them.

In comparison to running numerous ad-hoc commands, Ansible Playbooks offer more sophisticated capabilities for sending tasks to managed hosts and are made up of one or more plays.
Yet Another Markup Language (YAML), which is simpler to understand than a JSON or XML file, is used to write the tasks in Ansible playbooks. Each playbook task is carried out sequentially for each host in the inventory file.

Ansible roles benefits:

1. Allowing easy sharing of code with others
2. Make larger projects more manageable
3. Can use community-supported roles from Ansible Galaxy
4. Can use rhel-system-roles as part of Red Hat Enterprise Linux

Understanding The Ansible Role Structure

Ansible role is defined by a common structure of subdirectories and files. The top-level directory defines the name of the role itself. Files are organized into subdirectories that are named according to the purpose of the role, such as tasks and vars. The templates and files subdirectories contain files referenced by tasks in other YAML files.

Ansible role subdirectories and their Functions

Creating a Role

ansible-galaxy command is used to create and manage Ansible roles. You can run ansible-galaxy init to create the directory structure for a new role. Specify the name of the role as an argument to the command. To use the roles, we need to add these roles to the playbook.

ansible-galaxy init <ansible_role_name>

Role directory created now we can use this according to our requirements.

To use any role, we create one playbook and from there we run the roles.

Deploy Web Server on AWS through Ansible Roles

I’ll be configuring Apache Webserver on this system itself. We’ll be following three steps

1. Download the software
2. Add the code on the document root
3. Start the service

• Use ansible-galaxy init to start your role and then remove any directories and files that you do not need.

• tasks/main.yml it’s the same as writing tasks in the playbook.

• Defining variable name and service name in vars/main.yml

• This code will be sent to the document’s root location

• Here we are achieving idempotency which means only restarting the service when there is a change in file name index.html instead of restarting it whenever the playbook runs.

• Using the Role in a Playbook

• Adding role to the playbook

• Let’s run the playbook containing the role in it.

$ ansible-playbook <name_of_playbook>

• Let’s try to hit the webserver from the terminal and then the browser.

Conclusion

We learned about roles, how to work with roles, and utilizing the concept of role to configure Apache webserver. Roles structure Ansible code in a way that allows reusability of the code. Ansible Galaxy is a public library where a lot of roles are written by Ansible users. It’s good practice to go through the library to check for the roles instead of creating them from scratch.

About CloudThat