I don't want to run my own infrastructure. But the commercial providers will scan your data, "unperson" everything they, the government, or the copyright holders don't like, and charge me a fortune for the privilege or withhold features.
If you write a playbook to install some software on your home network, you have some YAML that took longer to write than it would have taken to do the task manually and isn't likely to be useful to anybody else. And without maintenance, that playbook will eventually decay and stop working. The scarf will continue to keep you warm forever.
Even if you go by the philosophy that something has to be useful to be valuable (not something I personally believe), toy projects have their place. Plus, they’re fun.
This is the part that has killed this as an activity for me. I really enjoyed the experience of setting up playbooks and so on for my home server (deluge, jellyfin, zoneminder, etc), but in the end I didn't have the time to do much more than make the occasional config tweaks and restart it all live, and once that started happening, the scripts were no longer of value, and it was clear there was no point.
That said, I know some Nix acolytes swear by it for this kind of thing, in part because it really forces you to do things using its declarative wrappers and intentionally doesn't provide workarounds the way containers do ("just shell in and change whatever, lol").
Many other things - Nextcloud, caddy, proxmox to name a few, are long gone now because they demanded hours of attention at unpredictable times, and I just can't be jeffed.
I still love tinkering with bits of tech on the home network, but I'm extremely wary of coming to rely on any of it until it's proven itself to need minimal ongoing babysitting.
'If you use ansible to configure some stuff on your home network, you have some self-hosted stuff at the end of it. You can use it yourself or let guests log in too.
If you use needles and threads, you have some tools that took longer to go to the shop and buy and use to make something than it would have taken to go to the shop and just buy the thing. And without regular use, you'll lose the needles and the yarn will tangle and discolour. The self-hosted services will continue to run.'
But also, why do you care so much about what other people do with their time? Live and let live, my friend. Nobody is forcing you to write ansible playbooks, build your own homelab, or comment on posts you view as a waste of everybody's time.
This is debatable. Some of those manual tasks you'd simply forget about and would end up with partially reproduced environment later, which is okay if you miss out on configuration that you don't actually particularly care about. It is much more annoying when you expect everything to work but realize that your workflows are randomly blocked because you forgot to manually install and configure some piece of software when reinstalling the OS or perhaps have to set up your IDEs completely anew because the configuration directories weren't preserved anywhere and are now simply lost. One of the benefits of using something like Ansible would be avoiding situations like this, or perhaps using something like NixOS (even though there are usability concerns presently).
In the more common case of using Ansible to manage servers (perhaps a homelab) as opposed to just using it for handling personal devices, the implications of this would be far more sinister - i've seen Java applications fail to work after migrating to a new OS release because fonts weren't installed, because someone forgot to document that step as necessary. And even if instructions are given (say, either when setting up some package anew, or reading your own documentation about your setup), there's no guarantee that you'll remember to follow all of them to the letter, or maybe you'll simply glance over a failure in one of the steps. That becomes even more likely as the size of your homelab and the count of your personal devices increases.
Clearly the impact of things like that happening is far lower in a homelab setting than it would be in a professional environment, but that also means that you'll essentially be pigeonholed into using some sort of an automation solution at your workplace (hopefully) to avoid situations like that, so also using it for your personal stuff is just the next logical progression. No one likes dealing with failures that aren't immediately apparent and could have been avoided entirely. I don't know about you, but Ansible's standard modules provide really good reusability, so i've definitely borrowed samples of how to do something from my personal setup for my work projects and vice versa (not verbatim, but syntax, how to use parameters and get things done in general).
> And without maintenance, that playbook will eventually decay and stop working. The scarf will continue to keep you warm forever.
This doesn't feel entirely accurate - everything, from your software, to your scarf will eventually decay. It's only a matter of time for the most part, though you can mitigate this by using more stable OS distributions like Ubuntu LTS (until very recently, i would have also recommended CentOS) or by using better materials for your scarf. Oh, and choose the stable versions of boring software, perhaps cut out the technologies that have the most rapid changes out of your stack entirely, until the development there slows down.
For me, that currently means:
- using Debian because it's stable and boring enough for my needs (both servers and desktop/laptop with XFCE)
- using Ansible for servers, treating personal devices and disposable otherwise (no attempt to preserve configuration, too much effort)
- using automated incremental backup software for the data, just in case
- manually provisioning any VMs/VPSes that i require, but having most of the configuration be similarly automated
- using Docker containers within those VMs/VPSes with Docker Swarm liberally, to separate software runtime environments from their data output and their configuration input
- using Docker Swarm to make managing all of that simpler and partially automate it, alongside something like Portainer for making that process more user friendly
- using Caddy to never have to deal with certificates manually, even though i manage DNS manually
- not updating software i don't expose publically and don't need the newest versions of (GIMP, Blender, LibreOffice, some private containers)
- using automated security upgrades within everything else, but also using the latest stable versions of server software, never bleeding edge
A lot of it is about finding what works for your particular circumstances and seeing which parts cause the most pain and then automating those.