yeah, that's not really the case with docker either I'm afraid
I feel like two places I disagree with this statement:
- Docker's official image library
- When a project you are looking to run has an official image they maintain
When those constraints are not met, I try to build my own image (based on the official images).
I try not to trust any other external images (with some exceptions from reputable sources such as linuxserver.io or Bitnami).
So yes, it is.
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.
... 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.
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.
That it uses containers is just an implementation detail, to me.
All the docker replacements will be useless to me if they don't come with a huge repository of pre-built relatively-trustworthy up-to-date containers for tons of services.
I love no longer needing to care much about the underlying distro. LTS? Fine. I still get up-to-date services. Red hat? Debian-based? Something else? Barely matters, once Docker is installed.
On my home server it even saves me from ever having to think about the distro's init system.
Bonus: dockerized services are often much easier to configure than their distro-repo counterparts, and it's usually easier to track down everything they write that you need to back up, and that's all the same no matter what distro they're running on.