I use quadlets instead - it’s part of podman and lets you manage containers as systemd services. Supports automatic image updates and gives you all the benefits of systemd service management. There’s a tool out there that will convert a docker compose config into quadlet unit files giving you a quick start, but I just write them by hand.

It won’t save you from doing a bit of work but you could use podman. There’s systemd integration so you can still start/stop/enable your services with systemctl while using docker/container images. You won’t be able to use docker-compose directly, but it’s usually not that hard to replicate the logic with systemd (Immich was a PITA at first (because they had so many microservices split into multiple images, but it improved considerably over the first two years).

I do this with NixOS quite a bit, and I’ve yet to use docker compose (although the syntax is different, it’s still the same process).

Docker compose pull; docker compose down;docker compose up -d

Pulls an update for the container, stops the container and then restarts it in the background. I’ve been told that you don’t need to bring it down, but I do it so that even if there isn’t an update, it still restarts the container.

You need to do it in each container’s folder, but it’s pretty easy to set an alias and just walk your running containers, or just script that process for each directory. If you’re smarter than I am, you could get the list from running containers (docker ps), but I didn’t name my service folders the same as the service name.

Why wouldn’t you just use Docker compose? It has NFS support build in and there are Ansible playbooks for it

I personally moved to podman since it integrates with systemd but it is a bit harder.

I never, ever use a bare docker run command unless it’s for a one-off, never used it again container. Other than actively working on a project, I can’t see why anyone would use that.

Docker compose for every stack, watchtower for the containers I’m not too worried about breaking changes on update.

Docker is far cleaner than native installs once you get used to it. Yes native installs are nice at first, but they aren’t portable, and unless the software is built specifically for the distro you’re running you will very quickly run into dependency hell trying to set up your system to support multiple services that all want different versions of libraries. Plus what if you want or need to move a service to another system, or restore a single service from a backup? Reinstalling a service from scratch and migrating over the libraries and config files in all of their separate locations can be a PITA.

It’s pretty much a requirement to start spinning up separate VMs for each service to get them to not interfere with each other and to allow backup and migration to other hosts, and managing 50 different VMs is much more involved and resource-intensive than managing 50 different containers on one machine.

Also you said that native installs just need an apt update && apt upgrade, but that’s not true. Services that are built into your package manager sure, but most services do not have pre-built packages for all distros. For the vast majority, you have to git clone the source, then build from scratch and install. Updating those services is not a simple apt update && apt upgrade, you have to cd into the repo, git pull, then recompile and reinstall, and pray to god that the dependencies haven’t changed.

docker compose pull/up/down is pretty much all you need, wrap it in a small shell script and you can bring up/down or update every service with a single command. Also if you use bind mounts and place them in the directory for the service along side the compose file, now your entire service is self-contained in one directory. To back it up you just “docker compose down”, rsync the directory to the backup location, then “docker compose up”. To restore you do the exact same thing, just reverse the direction of the rsync. To move a service to a different host, you do the exact same thing, just the rsync and docker compose up are now being run on another system.

Docker lets you compact an entire service with all of its dependencies, databases, config files, and data, into a single directory that can be backed up and/or moved to any other system with nothing more than a “down”, “copy”, and “up”, with zero interference with other services running on your system.

I have 158 containers running on my systems at home. With some wrapper scripts, management is trivial. The thought of trying to manage native installs on over a hundred individual VMs is frightening. The thought of trying to manage this setup with native installs on one machine, if that was even possible, is even more frightening.

Don’t auto update. Read the release notes before you update things. Sometimes you have to do some things manually to keep from breaking things.

But, how do folks manage this mess?

I generally find it less of a mess to have everything encapsulated in docker deployments for my server setups. Each application has its own environment (i.e. I can treat each container as its own ‘Linux machine’ which has only the stuff installed that’s important) and they can all be interfaced with through the same cli.

Is there an analogue to apt update, apt upgrade, systemctl restart, journalctl?

Strictly speaking docker pull <image>, docker compose up, docker restart <container>, and docker logs <container>. But instead of finding direct equivalents to a package manager or system service supervisor, i would suggest reading up on

1. the docker command line, with its simple docker run command and the (in the beginning) super important docker ps
2. The concept of Dockerfiles and what exactly they encapsulate - this will really help understand how docker abstracts from single app messiness
3. docker-compose to find the equivalent of service supervision in the container space

Applications like immich are multi-item setups which can be made much easier while maintaining flexibility with docker-compose. In this scenario you switch from worrying about updating individual packages, and instead manage ‘compose files’, i.e. clumps of programs that work together to provide a specific service.

Once you grok the way compose files make that management easier - since they provide the same isolation and management regardless of any outer environment, you have a plethora of tools that make manual maintenance easy (dockge, portainer,…) or, more often, make manual maintenance less necessary through automation (watchtower, ansible, komodo,…).

I realise this can be daunting in the beginning but it is the exact use case for never having to think about downloading a new Go binary and setting up a manual unit file again.

docker compose CLI.

KISS, never did me wrong.

I just use watchtower to update automatically.

Docker has a logs command.

Each app has a folder and then I have a bash script that runs

Docker compose up -d 

In each folder of my containers to update them. It is crude and will break something at some stage but meh jellyseer or TickDone being offline for a bit is fine while I debug.

Yeah, I have everything as compose.yaml stacks and those stacks + their config files are in a git repo.

I use Dockge to manage everything.

Check out Dockge. It provides a simple yet very usable and useful web UI for managing Docker compose stacks.

Watchtower for automated updates. For containers that don’t have a latest tag to track, editing the version number manually and then docker compose pull && docker compose up -d is simple enough.