[spenczar5]

They don’t quite do the same things. Systemd will do stuff like ensure the service is restarted if it ever crashes. It can also make sure system-level dependencies are up and running (“service B depends on service A, so wait for A to be up before trying to start B”).

Performance is not an issue in most docker setups you would ever use, correct.

[WhatsName]

Acutally, there are docker-compose primitives that solve just that (restart: always/on-failure and depends-on: servicename.

I think it mostly comes down to what layer of abstraction you like working at.

[spenczar5]

True, Docker-compose has a lot more overlap with systemd.

But it doesn’t have system-level dependencies. For example, in systemd I can wait for a network interface to be up and have an IP assigned by DHCP. As far as I am aware, docker compose knows about the docker network and its own containers, but not the system more broadly.

Also, you will likely want it to run for a long time, so something has to trigger the docker-compose process to start and restart it. You might want it to restart in case the OOM killer knocks it over. That daemom stuff is what systemd is good for.

[stryan]

Problem is you can't have it depend on anything outside of docker i.e. I can't write a docker-compose file that waits for an NFS mount.

[BossingAround]

Podman can generate systemd units for managing containers IIRC.

[MonkeyClub]

Yep, that's right: https://docs.podman.io/en/latest/markdown/podman-generate-sy...