Chapter 8: Composing Reusable Ansible Content with Roles

For many projects, a simple, single Ansible playbook may suffice. As time goes on and projects grow, additional playbooks and variable files are added, and task files may be split. Other projects within an organization may want to reuse some of the content, and either the projects get added to the directory tree or the desired content may get copied across multiple projects. As the complexity and size of the scenario grow, something more than a loosely organized handful of playbooks, task files, and variable files is highly desired. Creating such a hierarchy can be daunting and may explain why many Ansible implementations start off simple and only become more organized once the scattered files become unwieldy and a hassle to maintain. Making the migration can be difficult and may require rewriting significant portions of playbooks, which can further delay reorganization efforts.

In this chapter, we will cover best practices...

Technical requirements

To follow the examples presented in this chapter, you will need a Linux machine running Ansible 4.3 or newer. Almost any flavor of Linux should do—for those interested in specifics, all the code presented in this chapter was tested on Ubuntu Server 20.04 Long-Term Support (LTS) unless stated otherwise, and on Ansible 4.3.

The example code that accompanies this chapter can be downloaded from GitHub at this link: https://github.com/PacktPublishing/Mastering-Ansible-Fourth-Edition/tree/main/Chapter08.

Check out the following video to see the Code in Action: https://bit.ly/3E0mmIX.

Task, handler, variable, and playbook inclusion concepts

The first step to understanding how to efficiently organize an Ansible project structure is to master the concept of including files. The act of including files allows content to be defined in a topic-specific file that can be included in other files one or more times within a project. This inclusion feature supports the concept of Don't Repeat Yourself (DRY).

Including tasks

Task files are YAML Ain't Markup Language (YAML) files that define one or more tasks. These tasks are not directly tied to any particular play or playbook; they exist purely as a list of tasks. These files can be referenced by playbooks or other task files by way of the include operator. Now, you might expect the include operator to be a keyword of Ansible in its own right—however, this is not the case; it is actually a module just like ansible.builtin.debug. For...

Roles (structures, defaults, and dependencies)

With a functional understanding of the inclusion of variables, tasks, handlers, and playbooks, we can move on to the more advanced topic of roles. Roles bring together these different facets of Ansible code creation to provide a fully independent collection of variables, tasks, files, templates, and modules that can be reused over again in different playbooks. Although not limited as such by design, it is normal practice for each role to be typically limited to a particular purpose or desired end result, with all the necessary steps to reach that result either within the role itself or through dependencies (in other words, further roles that themselves are specified as dependencies of a role). It is important to note that roles are not playbooks, and there is no way to directly execute a role. Roles have no settings for which host(s) the role will apply to. Top-level playbooks are the glue that binds the hosts from your...

Summary

Ansible provides the capability to divide content logically into separate files. This capability helps project developers not repeat the same code over and over again. Roles within Ansible take this capability a step further and wrap some magic around the paths to the content. Roles are tunable, reusable, portable, and shareable blocks of functionality. Ansible Galaxy exists as a community hub for developers to find, rate, and share roles as well as collections. The ansible-galaxy command-line tool provides a method to interact with the Ansible Galaxy site or other role-sharing mechanisms. These capabilities and tools help with the organization and utilization of common code.

In this chapter, you learned all about inclusion concepts relating to tasks, handlers, variables, and even entire playbooks. Then, you expanded on this knowledge by learning about roles—their structure, setting default variable values, and handling role dependencies. You then proceeded...

Questions

1. Which Ansible module can be used to run tasks from a separate external task file when a playbook is run?

   a) ansible.builtin.import

   b) ansible.builtin.include

   c) ansible.builtin.tasks_file

   d) ansible.builtin.with_tasks

2. Variable data can be passed to an external task file when it is called:

   a) True

   b) False

3. The default name of the variable containing the current loop value is:

   a) i

   b) loop_var

   c) loop_value

   d) item

4. When looping over external task files, it is important to consider setting which special variable to prevent loop variable name collisions?

   a) loop_name

   b) loop_item

   c) loop_var

   d) item

5. Handlers are generally run:

   a) Once, at the end of the play

   b) Once each, at the end of the pre_tasks, roles/tasks, and post_tasks sections of the play

   c) Once each, at the end of the pre_tasks, roles/tasks, and post_tasks sections of the play and only when notified

   d) Once each, at the end of the pre_tasks, roles/tasks, and post_tasks sections of the play and only when imported...