Creating portable roles for Ansible

Before attempting to follow this recipe, I recommend having some basic knowledge of Ansible and how to write an Ansible playbook. If you’ve never written an Ansible playbook, I recommend following the Creating a playbook guide from the official Ansible documentation. That can be found here: https://docs.ansible.com/ansible/latest/getting_started/get_started_playbook.html.

In this recipe, you will learn how easy it is to move things around when using Ansible roles. When I first started using Ansible, I wrote my playbooks using tasks only. This to me seemed like a logical approach at the time and was more akin to traditional scripting since everything happened in chronological order.

The problem with writing playbooks in this way is there are no clear dependencies, and the tasks are defined along with the hosts, all in the same file. If you wanted to move things to another playbook, you’d have to be careful to grab the correct dependencies with each task, and you may be repeating yourself unnecessarily since tasks on their own are not reusable. As your playbooks become more complex and/or increase in size, you’ll eventually want something more portable for the sake of manageability.

According to Red Hat, roles are designed to be self-contained portable units of automation.

Organizing your tasks into roles will allow you to easily reuse them and share them with others. In fact, if you visit Ansible Galaxy (https://galaxy.ansible.com/) you will find plenty of content in the form of pre-packaged units of work referred to in Ansible as roles and collections. It’s much easier to reuse and share Ansible roles as organized units of automation because they are decoupled from the rest of the Ansible playbook framework.

If you’re a programmer, you can think of roles as functions or methods. Easy enough? Let’s get cooking!

Getting started

For this recipe, you will need the following:

• Oracle Linux
• Ansible

Refer to the Technical requirements section at the beginning of this chapter if you need help installing Ansible.

How to do it…

It’s not difficult to convert a series of tasks into roles. It’s really just a matter of stripping out the tasks and organizing them into categories that represent a role. This recipe aims to describe that process, and hopefully by the end, you will have a good understanding of how to do the same with your playbooks.

Original playbook

To kick things off, let’s first take a look at a playbook that doesn’t leverage roles so we can dive into what needs to be done.

A typical playbook that does not leverage roles looks something like this:

Figure 8.18 – Long playbook without roles

Note

The screenshot fades out at the end because it’s a long playbook and the entire contents of the playbook are not important.

This playbook automates several tasks. First, it creates a standard user if they do not already exist, then it installs Podman via the container-tools AppStream module, after which it launches an NGINX container, and then eventually it proceeds to upgrading all the packages on the system and checking whether the system needs to be rebooted.

As you can see from this example, if you write all your tasks directly into a playbook, it doesn’t take long for that file to become massive and unwieldy. Before long, you will find yourself repeating preparatory tasks throughout, and you’ll most likely add hash marks at the beginning of each line for unnecessary tasks, which will make the automation engine see it as a comment rather than code – you might even find yourself toggling between disabling and enabling tasks in order to target a specific task when running the playbook. This can become overwhelming, and if you’re not careful, you might end up removing bits of code when you don’t need them (even though sometimes, you might need them). Roles offer a better way to organize your playbooks. In fact, you can write as many roles as you want, and neatly call them in the playbook – this makes the playbook far easier to read and maintain over time.