Ansible is abysmal. I don't know why anyone still chooses it. It's a mess of yaml and what feels like a million yaml files that is always extremely hard to follow. Honestly writing some python, or bash is a lot easier to follow, read, and understand. The only thing it has going for it is the inventory system. I wish ansible would die already.<p>The tips mentioned in the article are helpful, but still beyond the initial development of roles, maintaining roles is a pain no one can alleviate. It is the perl of automation. I wish people would stop using it. I've yet to start a job where people haven't regretted going towards ansible.
I'm using ansible for some years already. The biggest game changer for me was ansible molecule [0].<p>I integrated it to the repo, where I store my code and it just runs all the test cases for my code. It saved me a bunch of hours of investigation in test environments before I even released the code. Highly recommend to try it even for a small project.<p>Apart of that play with ansible strategies if you have more than one server to apply the role. It really might save you some minutes of a runtime.<p>[0]: <a href="https://molecule.readthedocs.io/en/latest/" rel="nofollow">https://molecule.readthedocs.io/en/latest/</a>
It's a damn shame it took until this article for me (and it appears some others) to learn about the console and the debugger; those seem like massive time savers! My own biggest helper has been to use "ANSIBLE_STDOUT_CALLBACK=yaml" wherever "ansible-playbook" is called (<a href="https://jpmens.net/2021/03/12/alter-ansible-s-output-on-debugging/" rel="nofollow">https://jpmens.net/2021/03/12/alter-ansible-s-output-on-debu...</a>). It makes the verbose output much more readable and is especially handy for tasks that can spew thousands of lines at ones (e.g. "apt update/upgrade").
Another one for the list is `--start-at-task` and `--list-tasks`, for those tasks that are statically imported. If you have a task bomb out, you can take over from where you left off. Doesn't work in all playbooks, if facts need to be set earlier, but it's still very useful and saves tons of time. Obvious, but I wish I knew that one earlier too.
At work we use Puppet and I have to say that although the DSL is much more expressive and nicer to use than YAML, Puppet's tooling sucks in comparison. There isn't really any way to test your Puppet code that I know of, you just have to apply it and check if it all looks good. Puppet doesn't have a set of good practices established either. Different companies use completely different repository structures, compiler settings, linter settings. Modules for managing common software like Docker are low quality and riddled with issues.<p>Ansible and Puppet claim to be declarative but it's a lie. Configuration management really needs a rethink. I know Nix exists but that has a huge barrier to entry and companies don't want to use something that isn't battle tested. In my view, the ideal config management tool would be fast, testable, and provably idempotent. It would also be as far away as possible from the Python/Ruby swamp that Ansible and Puppet are stuck in.
The `--step` flag will definitely be useful for me, didn't know about that.<p>My one tip I'll add is to use the `--diff` argument when running a playbook to print out the specific changes made for each step. For debugging, use `--diff --check` to see all the changes that will be made - useful if it's been a while since you last run your playbook over a host.
I have used Ansible for some years. I recently switched jobs to a company having no automation on VMs. And we are migrating our workload to managed services in the cloud (managed Kubernetes), I have to say I'm relieved I don't have to deal with Ansible again. It's probably very efficient in many ways, but just copying a file/directory with the correct options is a bit of pain in Ansible. Having not to worry about VMs anymore is a huge win for me at least. /OffTopicEnd
Over the years I've tweeted Ansible tips, and Ansible Gotchas for my own memory and others<p><a href="https://twitter.com/search?q=from%3Amoreati%20ansible%20tip&f=live" rel="nofollow">https://twitter.com/search?q=from%3Amoreati%20ansible%20tip&...</a>
<a href="https://twitter.com/search?q=from%3Amoreati%20ansible%20gotcha&src=typed_query&f=live" rel="nofollow">https://twitter.com/search?q=from%3Amoreati%20ansible%20gotc...</a>
I wish I had read this a couple of weeks ago. I am new to Ansible but needed to use it to migrate a legacy system. I’m not really accustomed to long build times and kept running out of things to do in the interim while I was waiting for it to break.
Maybe a stupid redundant slightly offtopic question, but I'll ask anyways:<p>What is the best way to couple Ansible with some git repository to automatically apply changes while still being able to trace and debug?