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?

  • suicidaleggroll@lemmy.worldEnglish
    1·
    5 hours ago

    There are two ways to maintain a persistent data store for Docker containers: bind mounts and docker-managed volumes.

    A Docker managed volume looks like:

    datavolume:/data

    And then later on in the compose file you’ll have

    volumes:
  datavolume:

    When you start this container, Docker will create this volume for you in /var/lib/docker/volumes/ and will manage access and permissions. They’re a little easier in that Docker handles permissions for you, but they’re also kind of a PITA because now your compose file and your data are split apart in different locations and you have to spend time tracking down where the hell Docker decided to put the volumes for your service, especially when it comes to backups/migration.

    A bind mount looks like:

    ./datavolume:/data

    When you start this container, if it doesn’t already exist, “datavolume” will be created in the same location as your compose file, and the data will be stored there. This is a little more manual since some containers don’t set up permissions properly and, once the volume is created, you may have to shut down the container and then chown the volume so it can use it, but once up and running it makes things much more convenient, since now all of the data needed by that service is in a directory right next to the compose file (or wherever you decide to put it, since bind mounts let you put the directory anywhere you like).

    Also with Docker-managed volumes, you have to be VERY careful running your docker prune commands, since if you run “docker prune --volumes” and you have any stopped containers, Docker will wipe out all of the persistent data for them. That’s not an issue with bind mounts.