I just aim for “good enough”. Does it work, does it meet my needs? That’s good enough, even if it isn’t exactly the right way.

Like right now I have a system that needs manual intervention if I shut it down, or it’ll come back up non-functional. But it works well enough so I’ll just fix that eventually. I like to spend my free time doing more social or productive stuff.

My motivation to use Ansible is fueled by disdain for manual non-scriptable configuration. I’ve had to use Windows for a couple years lately, and the absence of programmatic access to many things annoyed me to no end.

Now, I get up in the morning and look to the east. I salute the sun and thank the fate for the chance to do proper configuration again. I don’t wade through dialogs for hours anymore. I don’t lose track of things that I’ve changed somewhere sometime. I’ll learn what the hell the difference between dconf and gsettings is, just to use one of them for all my desktop settings forever. I will have this config for years to come, and I will put more things in it bit by bit.

Now, if Ansible’s config language wasn’t a naive reinvention of Lisp, that would be great.

My personal selfhosting repo is just about 2 years old with 750 commits now, and probably more than 60 containers running. It’s not because of one great effort or design or anything, just setting up a service or two when I find it interesting every few weeks, and trying to make all my setup consistent. Almost everything is deployed as a container run by Podman quadlets, files mounted in /var/opt, config etc copied into place by an ansible script. But not everything, sometimes getting it working was easier without the sensible or I needed to do some funny networking.

TLDR: Coming back again later, and making that easier.

It’s great to give your brain daily workouts on the ins and outs of systems, but if you’re feeling burnt out, you’re doing that too much, probably, and my guess is, it’s coming in at moments when you were trying to solve some other, more interesting/relevant problem.

It comes down to whether you’re trying to self-host, or trying to learn Linux at a level where you could get a job doing it. Often it’s a bit of both, so don’t feel like you need to make that decision right now.

But my advice: whatever you’re hosting, use their recommended easy way to host it. In most cases, this means running a container. In most cases, Docker. If you can wrap your head around using docker compose files, your practical problems are reduced by an insane amount, and idiocy at the developer level becomes your only concern. For instance, I used to run Tandoor, but the dev pushed changes into their “stable” docker container that failed to properly migrate my data, and the whole thing cacked. But that wasn’t a system problem on my end, it was a case of a dev who was more interested in playing around with data than with providing a stable app.

So, if you take this approach, which I absolutely do recommend, the one thing you need to be sure of is that you have a good backup strategy, and that you backup before you do any pulls of new images. Docker allows you to select old versions so if you don’t like changes that get pushed on something, likely you can just rebuild the old version, but the changes might mess with your database migrations, so you need those backups. Other than that, you cannot go wrong with Docker, if you just want the damn thing to work, rather than get daily aggravating lessons in esoteric systems problems which are above your paygrade.

Don’t use Ansible and use Nix instead.

Seriously though give yourself time and a solid goals you want to achieve, it’ll take time and it’ll be worth it as

ditch ansible

learn nixos

be motivated