- In this video I'm going to tell you about Galaxy.
So what is Ansible Galaxy?
Ansible Galaxy or galaxy.ansible.com,
is a community website behind Ansible.
And it is mainly used
for providing access to roles and collections.
If you use galaxy
you can easily find the content that you need
even the description and the information, all about it.
There's an ansible-galaxy command line,
we've already seen it in the previous video
which you can easily use to work with your content.
And you can use ansible-galaxy collection to
manage collections or ansible-galaxy role to manage roles.
Instead of spending a lot of time in slides about galaxy
let's just go check it out.
So galaxy.ansible.com
is where you go to.
This is Ansible Galaxy.
In the past Ansible Galaxy was all about roles.
Nowadays, Ansible Galaxy is also about collections.
But it's easy to work with
once you understand what you're looking for.
So let's do a search and let's go
for this nginx that we've used before.
So I'm using nginx and I'm pressing enter.
Now what is happening?
Well to start with you see 37 collections.
Collections are a preferred way
to work with Ansible contents nowadays.
So that makes sense.
And you can see that in the Ansible Galaxy collection
there are three roles that are available
but you can also use a filter.
If you just want to see your roles
then you select role from the filter and you see the roles.
First, I would like to talk about these roles independently.
That's especially convenient
if you're still on Ansible 2.9 and earlier.
Let's check out this nginx role.
This is the nginx role that we have used before.
So here is the website.
This is Mr. Geerlingguy.
This is one of the main people in the Ansible community.
And Mr. Geerling has created this role.
So you can find some information,
including the information on how to use it.
The minimal Ansible version quite important as well.
And supportability,
that's the information on where
you can use this specific role.
And also quite convenient, there is a Read Me.
So if you want to figure out how to use this role
then here you can see it.
Most roles have a very detailed documentation.
Of course the documentation
all depends on the quality of the role.
Some documentation is quite good.
Some documentation sadly is not.
Now behind Ansible Galaxy
there is also the Ansible Galaxy command.
My advice, use the Ansible Galaxy website
to find the content that you need
and then use the Ansible Galaxy command for everything else.
So I'm using ansible-galaxy role,
minus h, minus h, to see what we can do.
Very convenient command is ansible-galaxy role list.
So if I do my ansible-galaxy role list,
I can see all the different roles that are installed.
And what do we see?
We see that currently there are three different directories.
Of course, these directories are hard coded
and can be further attuned from the ansible.cfg.
But if I use ansible-galaxy role install,
by default it ends in home/ansible/.ansible/roles.
So, you know what, let's go check out
this /home/ansible/.ansible/roles
to see what a role is really looking like.
I think it's worth having some insight into the roles.
So geerlinguy.nginx
and we can see different directories.
The role structure, the role contents is structured
between different directories.
And if you use the Linux three command
that's an easy way to figure out
how these roles are organized.
To start with there's default and vars.
These are about variables.
So default is your default variables.
They can be overwritten and vars is
in many cases operating system, specific variables.
Then we have the tasks.
Every role has task, and the convention is
that the main playbook in any directory is the name main.
So we can see main.yml containing the main task.
And then you can see that there are setup playbooks as well.
I'll show them in a while.
Apart from that, another important directory is the handlers
and the less important directory is the templates.
So if your task are triggering handlers
they are right here.
And if your tasks are using templates
they should be stored in the templates directory.
Now, if you really want to understand what's going on
we should go to the tasks directory.
And from there open main, main.yml.
So here we go, the main.yml and what do we see?
We see main playbook basically.
Well, it's not a playbook,
it's a collection of tasks, a collection of tasks
that through the role is going to be included
in your playbook.
And what do we see?
Well, we can see a very smart way to make it,
to make it work on any distribution.
So we have include vars,
which is using ansible_OS_family.yml.
Ansible_OS_family as you probably recognize
is an Ansible fact.
So it will include the Ansible fact for the specific
distribution family that you are using.
If we don't have nginx user,
then we are going to use set fact.
If ansible_OS_family equals RedHat
or ansible_OS_family equals Rocky.
Then we are going to install desks according to setup
RedHat.yml, et cetera, et cetera, et cetera.
And this is how a role is structured.
Now let me show you just one example,
the setup RedHat.yml.
Wow, that's a big collection of tasks, of course not.
Roles and tasks and everything else is organized
in a way so that it is readable.
And here you can see tasks that are specific
for RedHat and that is all.
This is what's gonna be done
if you are on the RedHat family
and if you're on the Ubuntu family, you get different tasks.
And that's exactly what a role is all about.
So while you are developing your own playbook,
you may think for yourself,
how am I going to handle this on Ubuntu?
How am I going to handle this on RedHat?
Instead of thinking about all of this for yourself
you can also use a role instead
and that is making your life a lot easier.