- In this video, you will learn about Ansible roles.
So what is a role?
Well, a role is a community provided resource
to make working with Ansible easier.
They provide standardized solutions for common tasks.
The idea is very simple to understand.
Let's say you want to use Ansible to configure Docker.
Do you really think
that you are the first person on the planet
who wants to use Ansible to configure Docker?
Most likely not.
That's where roles come in.
From the community,
different members of the community create roles
and they publish these roles on Ansible Galaxy.
And the nice thing is,
you can fetch them from Ansible Galaxy,
include them in your playbooks,
and just use them as standardized code.
And that allows you to focus on the things
that need to be different in your environment.
That's what roles are all about.
So, yeah, that's what I just said.
Instead of finding out yourself,
you can use community provided roles in your playbook.
And the only thing you need to do,
is to add site-specific configuration using variables
and learn everything else from the roles.
You can also work with customer roles
where you create your own roles.
That will be the next step.
If you think that there is not sufficient roles available,
you can develop some for yourself.
When you are working with roles,
it's important to understand task execution order.
Tasks in roles are normally executed
before other tasks in the playbook.
If you want to change that behavior,
you can you can use pre_tasks
to execute tasks before the role.
That is where you need to make sure
that your system is updated,
some configuration is started,
firewall software is installed,
or whatever task you need to take care of,
and which is not taken care of by the role.
So if it isn't taken care of by the role
and if it's important to happen
before you run your playbook, run pre_task.
If your pre_tasks are using handlers,
then handlers that are triggered by pre_tasks
are also executed before the roles.
Let's go check out an example.
So the roles example are in the Git repository in roles.
So what do we have?
We have Nginx role,
and in Nginx role, we are using Geerlingguy.nginx.
And this role is going to be executed only on Ansible two.
In fact, we can even make it more minimal.
This is all that we need.
So you need to tell where the role needs to be executed,
and you need to specify the names of the roles
that you want to execute.
Notice that you can include more than one role.
So here, I'm using one role only, which is pretty common.
But if in the playbook you are creating
a solution-based on multiple roles,
you can include all of them right here
in the order in which you want to include them.
There's one requirement though,
and that is that, Geerlingguy Nginx role is installed.
I will tell you later how you can easily find roles,
but for now, Ansible Galaxy minus minus help.
I like using the minus minus help
especially since the Ansible Galaxy command
has changed with the appearance of the collection.
There we can see there's a role
and then using install Geerlingguy.nginx.
So that is downloading the role
that is developed by Mr. Geerling.
Next, I can use Ansible Playbook
just the way we used to do it
on this Nginxrole.yml.
So here we can see that Ansible Playbook
Nginxrole.yml is working.
So it is doing everything
that it is requested to do in the role.
That might take a minute if there is no conflicts.
Notice that because of the HTTPD,
that we've been working with throughout in this course,
we might have an issue.
If HTTPD is already listening on part 80,
you're not going to be able to work with Nginx
but that's not an issue here.
And that's an example of how you can use roles
in an easy way.
Now let's go and investigate
what is really happening when you are using roles.