The only negative I had with it was that podman in Debian 13 missed a lot of auxiliary tooling so troubleshooting why unit files weren't generated was a combination of anger, guessing and journalctl.
Yeah I was shopping around for something like this too before just translating the docker compose specs to .service-files. Didn't find anything that was particularly convincing. Most of the value of systemd (in my case) is from breaking out of the limitations of docker-compose.yml anyway, so it's likely a lost cause.
Though as I alluded to in the post, drop-ins should not be slept on.
dijit | a day ago
i wonder if anyone has developed a system to translate docker compose into systemd run…
The format is really ubiquitous already, so much that a lot of my deployments are creating VMs that just run a single compose setup….
kwas | a day ago
https://github.com/containers/podlet
miro | 6 hours ago
I use podman-quadlet every opportunity I get.
The only negative I had with it was that podman in Debian 13 missed a lot of auxiliary tooling so troubleshooting why unit files weren't generated was a combination of anger, guessing and journalctl.
marginalia | a day ago
Yeah I was shopping around for something like this too before just translating the docker compose specs to .service-files. Didn't find anything that was particularly convincing. Most of the value of systemd (in my case) is from breaking out of the limitations of docker-compose.yml anyway, so it's likely a lost cause.
Though as I alluded to in the post, drop-ins should not be slept on.
You can e.g. put a config in
and it will be injected in
Very good for avoiding duplication (along with parameterized units, as also shown above)