What is the killer feature that will make me want to switch from Docker Compose to Podman Quadlets?
replies(7):
1. Podman is simpler than Docker. There is no long-running daemon. Rootless is default.
2. Quadlets can be managed as systemd services, giving me the same tools to manage and view logs for system daemons and containers.
Quadlets have been especially nice for bundling up an AI app I wrote as a cloud-init file, making it easy to deploy the hardware, software and models as one artifact.
Making systemd a necessary dependency to run > 1 container kinda negates many of the the nice advantages that podman has of not requiring root.
podman compose doesnt require root and would serve as a substitute but it's a very neglected piece of software.
It was a shitty decision that renders it just "a less popular docker" and not "a better docker".
Podman has a better architecture than Docker in that it can easily run on a non-privileged user.
Quadlet (aka podman-systemd.unit) is a podman-systemd integration which can make it easy to launch and orchestrate podman containers via systemd. You can get all if the systemd dependency handling, require other units to run after a container finishes, and all sorts of other useful things. Systemd "user" units (systemctl --user) also works here with the containers running as a non-privileged user in a non-root systemd context.
Just to be clear, Quadlet is just an integration and you can still run podman without it. You can still run podman on non-systemd systems as well.
systemd runs on a linux host, the rootless container runs on a linux host, controlled by `systemctl --user ...`.
Just to be clear we're talking about QUADLETS, red hat's recommended way to orchestrate containers.
>Just to be clear, Quadlet is just an integration and you can still run podman without it.
Just to be clear, nobody was unclear about that.
It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service.
Hope that helps.
and that particular init process did way more than any init process ever should even before somebody had the bright idea to add "docker compose substitite" to its ever growing list of responsibilities.
you could put a word processor and games in their too if you really wanted. is that a good idea? ill leave that for the reader's judgment.
From the podman docs:
> Podman supports building and starting containers (and creating volumes) via systemd by using a systemd generator.
Putting aside all the other issues one may have with systemd, this feels like a decent feature for a service manager to have (custom generation of service specifications).
> bright idea to add “Docker compose substitute”
Why is this so revolutionary? Docker-compose is just a service manager for containers. Systemd is a service manager. Systemd allowing podman to give it “container” features seems pretty reasonable.
systemd itself isn’t acting as a docker-compose substitute. Podman simply translates unit files containing docker-esque configuration (image name, volumes, etc.) into plain systemd unit files that contain (among other things) an ExecStart line that starts the container with the proper arguments.
You can complain that you don't liken systemd's design or that it does too much (very overplayed complaint, but ok).
But that's an orthogonal point to the initial complaint you've made that it's somehow bad that this requires systemd to run.
That complain is moot, since you'd be running systemd anyway, with or without those containers. And it's double moot, because you can run > 1 containers (with podman) without root too.
(It's also wrong that systemd was added container compose capabilities - podman is what translates things to systemd "speak")
Oh, you were quite unclear. Also wrong in saying you need systemd with podman to orchestrate multiple containers without root.
>It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service.
It's not "red hat's recommended way to orchestrate podman containers" in general. It's "red hat's recommended way to orchestrate containers on top of systemd", that its whole point.
Nothing nasty about it either, you'd already be running systemd on your redhat system (and many non red-hat ones).
It's not at all orthogonal. Making the "default" way to run > 1 containers together require the init process is fucking stupid.
Similar to how requiring ROOT to run containers was a stupid design decision made by docker.
This decision to make quadlets the "default podman orchestrator" and to double down on it relegates podman from being "a better docker" to just "docker just with different design mistakes".
>That complain is moot, since you'd be running systemd anyway
false. systemd is not the only pid 1 in existence (much as it likes to pretend it is). when you run a container inside a container there also isn't a systemd.
>And it's double moot, because you can run > 1 containers (with podman) without root too.
except there is NO good orchestration system for doing that. podman compose is a steaming pile of shit. quadlets requires systemd which requires root. docker compose requires a root service. you can run podman compose inside a container but not quadlets.
might as well just use docker at this rate.
>That complain is moot
Your comment comprehensively missed my point 3 times. It's triple moot. It would have been better left unmade.
I explicitly said thay it wasnt needed and that there werent other ways just that it was the recommended way.
>It's not "red hat's recommended way to orchestrate podman containers
It is.
> what else would you like to bundle in the init process? docker compose as well? maybe kubernetes too. a webserver? a word processor perhaps? maybe an email client?