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.

Exactly my approach!

So when I plug it in it copies/syncs the things on my computer, anyone knows somethign like that?

So you want to sync files from a drive whenever you plug it in to the computer? Sounds like a udev + rsync solution. Udev mounts the drive and runs rsync.

Rootless LXC containers, TLS. In my case, I have both VPS and my own hardware, so every sensitive data is hosted on the hardware only.

If you’re already self-hosting:

Document your setup. Write guides. Make it easier for the next person.

Heck yeah! This is exactly what I’m trying to do: https://codeberg.org/lch361/infrastructure.lch361.net (in the future I’m planning to move all code to a self-hosted Forgejo service, especially when it’ll implement federation). Infrastructure as code, performance metrics, automation - it’s all there. It’s not just a matter of self-hosting and privacy anymore. It’s an effort to make the engineering behind that more approachable.