Good idea.

Honestly, I learned Ansible from my environment. First, I explored a piece of Ansible code written by my colleague. Then discussed with him and got understanding of what Ansible is capable of. Started learning it myself. Read Ansible documentation, wrote a couple of playbooks. After realizing that these playbooks will become part of the project, I got concerned with code quality and maintainability. So I asked around, watched a video about Ansible from someone I knew and searched Ansible repositories on GitHub. This is where I discovered roles and tags in Ansible, and also recommended directory layout.

Pain points?

• Ansible documentation’s search bar is rather inconvenient to use. I recommend navigating reference chapters directly.

• Also I wasn’t able to easily mirror Ansible’s documentation to localhost with wget only. I usually prefer doing that, so I could learn offline. It seems like if you want to save documentation for yourself, to display it you’d need Read the Docs installed as well. I don’t like the complexity.

• Syntax checking leaves a lot to be desired. ansible-lint is only okay for that. You can have a syntactically correct role and a playbook that uses it, yet still get errors when running it. Playbook will be considered correct even if you specify role variables that do not conform to argument specification.

• Speaking of argument specification. Ansible allows to set any variables for role. meta/argument_specs.yml, however, can’t validate all possible variables (Ansible version 2.21.0). For instance, it can validate that a variable is a dict, but can’t validate dict values if keys are supposed to be arbitrary. Also argument validation runs always, even if selected tags should omit the play execution. These 2 reasons were why I just stopped bothering about argument_specs.yml in my project at all.

• For plays, Ansible has “Gathering facts” step. And it just takes very long time to execute while collecting information that I don’t always use in a play. Instead, I made gathering facts explicit and I’m using ansible.builtin.setup manually. More code, but faster testing.

• Overall, the hardest part of Ansible isn’t writing correct Ansible code. It’s making sure it runs without errors on the first attempt.

One thing I found significantly helpful is Ansible language server. It allowed me to catch around half of errors before leaving the editor and running a playbook. It also allowed me to finally consult the module’s keywords offline, instead of fetching online documentation every time I forgot parameter syntax. And it also uses ansible-lint, which often gives hints for making code more maintainable for future self.

And about learning Git? I learned software development before Linux engineering. I kinda learned Git by examples, man pages, sometimes documentation. But right now, I wish I knew earlier about Lazygit. It makes working with Git simpler and faster. Knowing Git CLI is still useful though, in case Lazygit TUI becomes constraining.