Comment on My self-hosted infrastructure, now as an open source code
punkibas@lemmy.zip 18 hours ago
I want to convert my homelab to infrastructure as code.
What resources did you find useful to learn it? any particular pain points?
I manage everything manually but it’s mostly docker in LXC on Promox, with some VMs mixed in. I’ve started learning git and some ansible with some books and courses I found, but would like to find the resources others found useful.
lch361@discuss.tchncs.de 3 hours ago
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
wgetonly. 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-lintis 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 aboutargument_specs.ymlin 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.setupmanually. 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.