And throw in that command,
ansible‑galaxy role install and then the name of the role.
Oh, it's already installed.
Okay.
And it's telling us we could do ‑‑force if we wanted to do a force upgrade,
for example, of that particular role version.
So that's really it.
You browse the website until you find the role that suits your use case,
whether it's managing SQL Server or whatever it might be.
You find the role and then you install it on your control
node using ansible‑galaxy role install.
And then,
the next thing I would do is I would inspect the role and
see what its contents are and so on.
So that might lead you to think about, well,
where does Ansible keep roles by default?
As you can see in the top of my terminal here, I ran good old ansible ‑‑version.
And it's got a path here for modules,
but this output doesn't actually show roles.
On my system,
I've got the default global, and you'll have this too of etc/ansible/roles.
That's the system default search location for roles.
But then any that you download under your user account are going to be stored
in your home folder in a hidden directory called .ansible.
So as you can see, if I run a directory listing on that roles folder,
notice here I have the oatakan.windows_update.
So let me try this.
Let me open up VS Code,
and let's have it open that windows_update custom role folder,
and we can just take a quick gander at it in VS Code.
And we should see no surprises,
especially if you're coming to this lesson from the previous one.
So we've got our requisite README file.
We've got our defaults.
Our files, in this case,
it looks like windows_update is happening actually
through a PowerShell function.
If we take a look at our tasks.
So it occurs to me as I'm scrolling through here,
nothing particularly profound but just a general caveat that any of these
roles that you happen to download from Ansible Galaxy,
make sure that you perform your due diligence and you do what
I'm doing right here and parsing through each of these
components and just giving it a spot check.
And I'll also want to test this in a development sandboxed environment.
That's just a general point.
I would be remiss if I didn't call that out.
So then to finish this up,
we can see the README of this custom role here. Galaxy is showing us
an example playbook where we've defined in our variables block
win_update_category_names, and those are going to be passed in as
parameters when the role is invoked.
And again, we're specifying for roles, the full qualified name,
which includes the username and the name of the role that they've added.