Today I submitted a role to Ansible Galaxy "initialises MySQL/Percona/MariaDB Server software on a host". While not my first Ansible role, this was the first time I released a role on Ansible Galaxy.
- The Ansible Galaxy has it's flaws, but I gave it a crack anyway
- The role is very basic and at the moment "installs MariaDB or MySQL community server, sets t he root password and creates databases and users if specified. You can also patch /etc/my.cnf"
- I have improvements planned for the future.
I doubt anyone refers to it as "the galaxy", but there you go. It's a strange place, at first glance there appears to be a complete abundance of roles with the promise of solving all your problems in double quick time. In my experience they rarely deliver though and when I have used them they have been nuisance to have as a dependency. The documentation is usually poor, they seem to get neglected by authors and they are impenetrable when you go to debug them. This is in part because Ansible, in recent time, has evolved at quite a pace and it doesn't lend itself to 'self documentation'.
Given all this, why did I bother contributing a role? 🤷 I can do better of course ... Probably not, in fact, certainly not. The initial commit is really only a prototype and doesn't support 33% of the distributions mentioned it's name. It's a start.
To be fair, I do like the Ansible Galaxy site itself. It's easy to use, the meta and packaging is well documented and imports from GitHub are easy. The linter which is executed on every import is also helpful.
The role in it's current form is very simple. It installs MariaDB or MySQL community server, sets the root password and creates databases and users if specified. You can also patch /etc/my.cnf. This is all that I require at the moment however I do have plans to add features, see below.
Developing the role knowing that it was potential going to be consumed by a larger audience for a generic purpose was an interesting process. It really made me focus, it highlighted the need for simplicity and compatibility. I also learnt a thing or two about the divergence of MariaDB and MySQL and learnt more than I cared to about the package versioning oddities in CentOS.
The role currently has some major limitations, which I plan to address going forward :
- Passwords are passed as parameters to the
mysqladmincommand on the server. The
commandAnsible module is used so there should be not reference in shell logs, however this is not the most secure method. Unfortunately it must be done this way for compatibility.
- The root password will only be set once. Changing the root password after it is initially set will not update the password on the server
- Users will only be created and have their password set once. Changing a user's password after it is initially created will not update the password on the server
- Removing users will not result in their deletion on the server
- Removing databases will not result in their deletion on the server
I have some other roles which I will be publishing soon, so stay tuned. Particularly interesting will be an OpenNebula management server and node role.
Thanks to Markus Spiske for the bread rolls photo I used with this post.