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?

  • hoppolito@mander.xyzEnglish
    30·
    14 hours ago

    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.