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

obscurity != security

that said, you gotta be safe and make sure you’re not committing keys, passwords, etc.

there is never a 100% security guarantee.

100% guaranteed security is literally impossible, nobody on the planet can guarantee that about anything. IDK if you realize but you’re basically arguing against FOSS security solutions.

Do you mean we Lemmy users shouldn’t do this, or IaC shouldn’t be done in homelab? I don’t understand your objection.

Wasn’t even aware of opentofu until now.

Every day is a school day