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.
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.
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.