How do y’all manage all these Docker compose apps?
First I installed Jellyfin natively on Debian, which was nice because everything just worked with the normal package manager and systemd.
Then, Navidrome wasn’t in the repos, but it’s a simple Go binary and provides a systemd unit file, so that was not so bad just downloading a new binary every now and then.
Then… Immich came… and forced me to use Docker compose… :|
Now I’m looking at Frigate… and it also requires Docker compose… :|
Looking through the docs, looks like Jellyfin, Navidrome, Immich, and Frigate all require/support Docker compose…
At this point, I’m wondering if I should switch everything to Docker compose so I can keep everything straight.
But, how do folks manage this mess? Is there an analogue to apt update, apt upgrade, systemctl restart, journalctl for all these Docker compose apps? Or do I have to individually manage each app? I guess I could write a bash script… but… is this what other people do?
You must log in or # to comment.
Each app has a folder and then I have a bash script that runs
Docker compose up -dIn 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 manage them with dokploy.com
I update them manually after checking if the update is beneficial to me.
If not then why touch a running system?
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.
Politically correct of course.
But from my own experience using Watchtower for over 7 years is that I can count on one hand when it actually broke something. Most of the time it was database related.
But you can put apps on the watchtower ignore list (looking a you Immich!), which clear that out fairly quick.
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 -dis simple enough.Adding here. Most docker containers support semver pinning! It’s a great balance between automated updates and advoiding breakage.
docker compose CLI.
KISS, never did me wrong.
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>, anddocker logs <container>. But instead of finding direct equivalents to a package manager or system service supervisor, i would suggest reading up on- the docker command line, with its simple
docker runcommand and the (in the beginning) super importantdocker ps - The concept of Dockerfiles and what exactly they encapsulate - this will really help understand how docker abstracts from single app messiness
- 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.
- the docker command line, with its simple
I use Dockge to manage everything.
+1 for Dockge.
So I have a git repo with all my compose files in it, some of the stacks are version pinned some are latest. With the git repo I get versioning of the files and a way to get compose files on remote servers, in the repo is a readme with all the steps needed to start each stack and in what order.
I use portainer to keep an eye on things and check logs, but starting is always from the cli
I just use watchtower to update automatically.
Docker has a logs command.
And being able to opt in just with a container label is super convenient
I use dockge. 1-2 years ago i started to selfhost everything with Docker. I have now 30+ Container and Dockge is absolut fantastic. I host all my stuff on a root Server from Hetzner and if they reveal a cheaper Server i switch. Since all my Stuff is hosted on Docker i can simple copy it to the new Server and start the Docker Containers and it runs.
In the docker folder with the docker-compose.yml of whatever docker container you want to upgrade:
docker compose pull && docker compose up -dAs others have said, for large groups of containers it’s helpful to use Watchtower.
Immich in particular warns to backup your database before an upgrade. Also be on the lookout for breaking changes which require you to alter your docker-compose.yml file before an upgrade.
Oh and after upgrades to remove any dangling images which sometimes take up a lot of space:
docker image pruneAlso if you want services to be interoperable, learn about docker networking now not later and remember for static IPs you must create a user defined bridge.
I think compose files are usually pinned to a version, or use a .env file that needs to be changed to update to a new version.
I personally don’t update very often; usually not until I’m forced to for some reason. I find that just checking the documentation for any upgrade/migration guides, and doing it manually is sufficient. I don’t expose this kind of stuff publicly; if I did, I’d probably update regularly.
Immich is a more touchy beast because it includes a mobile app and the mobile app and the docker container need to generally be either the same version, or within a few versions of one another. There was a while where I forgot to update the server for a while and the mobile app kept being updated on my phone and stopped backing up photos because it could no longer communicate with the server.
I don’t expose services to the outside world either, but I still enjoy keeping things up to date. Gives me something to do.
Check out Dockge. It provides a simple yet very usable and useful web UI for managing Docker compose stacks.
Was looking if anyone mentioned it!
I started with portainer but it was way too complex for my small setup. Dockge works super well, starting, stopping, updating containers in a simple web interface.
Just updating Dockge itself from inside Dockge does not seem to work but to be fair I didn’t look into it that much yet.
Can Dockge manage/cleanup unused images and containers by now? That’s the only reason I keep using Portainer - because it can show all the other stuff and lets me free up space.
No, not through the dockge UI. You can do it manually with standard docker commands (I have a cron task for this) but if you want to visualize things, dockge won’t do that (yet?).
I’d suggest to put the compose stacks in git and then clone them either manually or with some tool.
For fully automated gitops with docker compose, check this blogpost
Strongly recommend komodo. I tried dockge and portainer but komodo was easy to install and has great features from scheduled updates and using compose files from a git repo. Also you can migrate existing apps to it without too much work
I just made the switch to Komodo last week. Komodo lxc managing 4 VMs across two proxmox hosts. Easily added all the existing servers and it just worked. I think any of these systems are probably overkill for my needs but Komodo had the nicest “fresh out the box, find the important stuff right away” feel to it. My two cents.
