> Bonus: dockerized services are often much easier to configure than their distro-repo counterparts
A hard no there.
Sure, some projects, after they started to publish their own Docker images concluded what it would be beneficial to expose more configuration options not buried in tons of .conf files - ie they started to support environment variables or have some script in the init what would dump the variables to the proper places.
Sadly, this works only for some projects, because if this is is an afterthought then you will have a pretty bad time figuring out why something doesn't work or not configured as you wish despite having all the knobs specified. The worst offender for was probably Gitea - it just ignored half of the settings until I found a combination what would trigger supporting some settings (!). Another offender is probably Nextcloud, it is easier to docker build a full image than to add SMB support to their official one with a published instructions on how to do so. And half the time it ignores 'trusted_hostnames' so it fires up and doesn't allow you to login because it doesn't know what 'nextcloud.yourdomain.tld' is it's own address.
Oh, don't let me start on Swarm on compose file shenanigans.
Just forcing them to record exactly where important files are saved and config files live has been hugely helpful. I like that it makes it easy to keep my config from being shit all over /etc with a thousand other files I will never want or need to touch, so my modifications to /etc on a typical server are small and tightly confined to a small number of files. What do I back up? It's right there in the "mounts" list. Have I backed up everything important? Add some dummy data, remove the image and do an "up" and if it still looks right, then yes, I have.
... and I don't have to re-learn any distro-specific config or packaging, for those dockerized services. Get it right once, and you're done.
> The worst offender for was probably Gitea - it just ignored half of the settings until I found a combination what would trigger supporting some settings (!)
Haha, that's actually one I run, and also one of the worst I've ever encountered. I found the Rootless version of their image much easier to deal with (I never got the other one to work at all) personally, for whatever reason. Part of the trouble is that Gitea's config file, and documentation thereof, is kinda a damn mess.
> my config from being shit all over /etc with a thousand other files
Yea, I was so involved in the previous comment what I forgot to say what this is what is actually helpful
> What do I back up? It's right there in the "mounts" list
Yep, I completely ignore the docker persistent volumes. My infra is running in VMs which are backed up by Veeam, so there is a bazillion of ways to recover data and services - and no need for full restores and volumes juggling if I only need a one file.
A hard no there.
Sure, some projects, after they started to publish their own Docker images concluded what it would be beneficial to expose more configuration options not buried in tons of .conf files - ie they started to support environment variables or have some script in the init what would dump the variables to the proper places.
Sadly, this works only for some projects, because if this is is an afterthought then you will have a pretty bad time figuring out why something doesn't work or not configured as you wish despite having all the knobs specified. The worst offender for was probably Gitea - it just ignored half of the settings until I found a combination what would trigger supporting some settings (!). Another offender is probably Nextcloud, it is easier to docker build a full image than to add SMB support to their official one with a published instructions on how to do so. And half the time it ignores 'trusted_hostnames' so it fires up and doesn't allow you to login because it doesn't know what 'nextcloud.yourdomain.tld' is it's own address.
Oh, don't let me start on Swarm on compose file shenanigans.