Ansible Galaxy Tutorial


In this final video before we start looking at some real world Ansible-managed system builds, we are going to take a look at Ansible Galaxy.

We have already used Ansible Galaxy a number of times in this series.

Back in the Ansible Roles tutorial video, we saw how we could use ansible-galaxy init __template__ to create our a template role directory prefilled with all the expected folders, and a main.yml file living neatly inside awaiting our further meddling.

We covered using a real Ansible role in the 'How to Manage Users with Ansible video' where we used the brilliant Users Role by mivok0 to abstract away the workings of implementing User Management.

That's really the selling point of Ansible for me - being able to jump over to the Ansible Galaxy website and within a few minutes have found a way to centralise, automate and manage some pain in the arse systems task that used to cost me a bunch of time, or worse, become a task I would leave for later (aka, never do, or never do properly).

How I Use Ansible Galaxy

Before we go further, I want to briefly touch on how I use Ansible Galaxy.

Having recently been forced to wipe my Ansible Master server to get a different task done, I was then caught with the chore of re-installing all the roles I had been using on my previous Ansible master.

Initially I had had enough forethought to make a note of my downloaded, in-use Ansible Galaxy roles in a file I'd called ansible_galaxy_roles. In there, I'd kept my list - but had become a little lazy on updating it. As such, after re-downloading all my roles using the ansible-galaxy install -r ansible_galaxy_roles command, I was still caught out a day after re-installing when I ran a less-often run playbook.

I had to figure out what had gone wrong (which wasn't that hard, the error message was good), and then remember the ansible-galaxy command, and then re-run the playbook.

I got frustrated.

I had already recently swapped to doing a git clone on any new role I had been using, so instead, decided to ditch the ansible-galaxy command and pull the files down locally. I would then remove the .git folder, and assume local control of the role.

Now, this obviously has its downsides - bug fixes, losing the community side of things, and anyone else using the roles to perhaps mistake me for their creator. As such, I don't delete the documentation or license files, if there are any.

The upshot being - I now keep any roles in my own local dev environment, and as such have much better visibility and management of my dependencies.

It works for me.

Benefits

I want to explain the benefits - to me - of doing this.

Firstly, I get to see all the Roles I use, locally. I mentioned this above.

Secondly, I can easily make any edits or config changes, particularly in the role defaults/main.yml, that better match my environment.

Thirdly, I have learned a ton by doing this. By reading other roles in more depth, I have found loads of tips and tricks to make my own roles better in the process.

Combined, these reasons outweigh the cons of infrequently, potentially having to dig the role back out on github and cherry pick any changes (or just re-download the whole, updated role again).

As ever though, do what works best for you.

Code For This Course

Get the code for this course.

Episodes