Is ansible really reusible? We had an ansible deploy for bringing up MySQL database. I stopped using the codebase and came back to it months later; and I spent two days trying to get it to work (it was an unholy combination of local and community yaml) and eventually just rewrote the damn thing as a bare sequence on literal MySQL (in 20 minutes I might add) and disabled verification - definitely worst practices - to get it to deploy.
Maybe the problem is that I'm not an ansible professional.
Ansible roles solve that. It's a way of organizing tasks in a way where you can use them from other playbooks and supply the configuration parameters for it.
And yes, there are public roles for bringing up MySQL, here's one of the more popular:
Some of that could be due to versioning... Ansible's releases always have breaking changes, so you can get into trouble if your setup is vastly different from when the playbooks were created. I think this is part of the point of a dedicated control machine, but unfortunately the documentation (last I checked) seems to neglect the importance of it.
Along the same lines, there are also .cfg files and roles that can live outside the root directory.
I've been able to get decent reusability out of roles, but that's mostly because I can live with my servers all being deployed the same way (e.g. they all have the same nginx config with minimal customization points and share the same certificates).
Usually virtualenv + requirements.txt + all configuration inside playbook repository should make for a painless experience without one (save for speed).
This is fairly anecdotal, but... The Ansible Galaxy is a repository of code/libraries that people have written and published to be consumed by others. I've _never_ been able to use anything I've found on the Ansible Galaxy in my environment because everything I've looked at has been so opinionated or inflexible it would be less work to write something that does the same job from scratch.
This is in stark contrast with my experience with the Puppet Forge, which my environment uses 20+ modules from for managing different parts of our systems.
Sounds like that was written as a single Ansible play and not using the more standard role-based structure. That's the equivalent of writing an entire program in a single main() with no other functions.
Honestly, this is going to sound absolutely terrible, but the easiest way I found around some limitations of mysql modules in Ansible is to create SQL statements using a template and just load that in.
Ansible is not idempotent, unless you implement that idempotency yourself in its awkward little YAML ecosystem.
Example: V1 of a playbook installs htop. V2 doesn't. Now, a machine that went through V1 then V2 has a different state than a machine that just went through V2. Of course, you can make V2 explicitly uninstall htop - but that's a hack, and while it's easy for this particular example it sucks for real life problems. And even if you implement explicit 'clean up after previous versions', then you have to manage those as well, figure out how long to keep them, make sure they don't have side effects on other machines (maybe something else installed htop and actually needs it?), etc.
>Example: V1 of a playbook installs htop. V2 doesn't. Now, a machine that went through V1 then V2 has a different state than a machine that just went through V2.
This has nothing to do with idempotence. Idempotence means you can apply the same action more than once, and all applications after the first are no-ops. In Ansible's case, that applies to its tasks; eg if you run a task that starts a service but the service is already started, the task simply succeeds without any other effect, as opposed to failing or some other behavior.
Maybe what we need is a set of CLI commands that mirror Ansible modules in performing idempotent operations through SSH and APIs.