We will start this module by examining roles.
Roles let you automatically load a variety of
Ansible artifacts such as variables, files,
tasks, and handlers based on a known file structure.
We will then discuss collections that are better integrated
with the more recent versions of Ansible.
Playbook modularity is an important strategy to help
you better organize your playbooks.
Here, we will discuss important includes along with tags.
Host delegation is a useful feature,
and we will discuss some examples and how it can be implemented.
You can, if you want, delegate facts to specific machines or groups of machines.
Finally,
we will end the module by examining the ways you can manipulate data in Ansible.
We have different types of filters and plugins.
There will also be some demos on host delegation and filtering.
So Ansible is a scalable task configuration management tool,
and we're not just concerned about the amount of a managed assets it can manage,
but also the complexity.
As we discussed in the previous modules,
Ansible has a number of features that helps you elevate the complexity of
larger or more complex playbooks across different contexts.
Ansible has a feature known as roles and allows you to
decouple complex jobs into smaller pieces making everything
more manageable and easy to use.
Roles let you automatically load a variety of Ansible artifacts,
such as variables, files, and tasks,
and handlers based on a known file structure.
Here, we are breaking apart the playbook into multiple files,
and after you group your content into roles,
you can easily reuse and share them with other users.
So consider a role to be something that you assign to a group of hosts,
such as the frontend.
So you would assign a front‑end role to the host that act in
your front‑end layer of your application stack.
So a role is a reusable playbook written in a way
where we can group it in a structure.
So if you have a front‑end role,
any files associated with the front‑end role would
go into roles/frontend directory.
So you may be thinking at what stage do I start using roles?
Well when you have more than three or four tasks,
these become good candidates to become a role.
You could have a role to set up a control node,
a role to set up a basic website,
you can even daisy chain all the roles together if you want to.
Roles really are a great way to organize your playbooks.
A role is very structured and lacks site‑specific data,
therefore,
it can be shared with others who can combine it with
their roles in their own playbooks.
So to combine roles in a playbook,
we have a role section that expects a list of roles.
So tasks in a role are normally executed before other tasks in the playbook,
and you can change this if you want.
For example, you may want certain software installed,
such as a firewall or patch before executing the role.
So here, we can have pre tasks and post tasks.
Pre tasks can be used if you want to run tasks before
or after you invoke your roles.
For example,
you might want to update the app cache before deploying your application.
For a post task,
it might be as simple as to send the notification to a
Slack channel upon successful deployment.
So Ansible allows you to define the order in your playbooks.
We have, firstly,
a list of tasks that execute before the roles with a pre task section.
Then we have a list of roles to execute.
Then we have a list of tasks that execute after a
role with the post task section.
Ansible supports a feature called dependent roles.
When you define a role,
you can specify that it depends on one or more other roles.
Ansible will ensure that roles that are specified
as dependent are executed first.
An example of this would be two roles requiring the network time
protocol installing a host before they are executed.
You could specify the insulation of an NTP server in both roles,
but this would result in a duplication.
Dependent roles would be perfect for this type of requirement.
So Ansible Galaxy is a community website for Ansible and is used
to provide access to roles and collections.
So we have an Ansible Galaxy collection and an Ansible Galaxy role.
We will get into collections in just a moment.
There is also an Ansible Galaxy website to find what you need,
and then you can use the Ansible Galaxy command
line to go and fetch this for you.
So the primary purpose of the Ansible Galaxy command line is to
download roles that the Ansible community has shared.
So as a best practice,
instead of finding out yourself something that has been done before,
you should use roles.
You then just need to add the site‑specific
configuration using variables in the playbook,
and then everything else can run from the role.