edit: Looks like it changed quite a lot. this looks so much nicer
edit2: I still need a tutorial. had so many errors come up. :(
Quadlet: Running Podman containers under systemd (mo8it.com) | 298 points | 68 comments | https://news.ycombinator.com/item?id=43456934
Where do quadlets fit in the container management landscape?
Running individual services that would have been RPMs? Docker compose? K8s?
And once all peripherals are seen and run correctly, I don't "manage" it as long as it works.
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.
https://docs.podman.io/en/latest/markdown/podman-run.1.html#...
I wanted to offer that you don't have to jump all the way to podman (and Podman Desktop) just to escape the Docker Desktop licensing problem. There are a lot of alternatives which a whole spectrum of "I am CLI savvy or not" interaction experiences
- Rancher Desktop is A++ and carries a friendly license https://rancherdesktop.io/ -> https://github.com/rancher-sandbox/rancher-desktop/blob/v1.1...
- colima (and the lima it wraps) -> https://github.com/abiosoft/colima#readme
- there's one from AWS called Finch <https://github.com/runfinch/finch> that some of my colleagues like better than colima; YMMV <https://aws.amazon.com/blogs/opensource/introducing-finch-an...>
systemctl --user ...To replace a single docker compose file, sounds like one needs to manually create a number of .container, .volume, .network, .kube files correctly so systemd can spin up a container pod? Is that what I'm reading? Is there nothing that can generate that from a docker-compose.yml?
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.
For servers where you don’t need the complexities of Kubernetes etc, using Quadlets is nice as you can manage containers as regular systemd services and no Docker daemon running as root.
Essentially this. Rather than adding anything on top of systemd (which is almost certainly running anyway) quadlets are a way of turning containers into systemd units, and directing systemd to run them
I think it is the lightest weight, but still convenient, way of running a container as a daemon, with all the pros and cons that implies
systemd runs on a linux host, the rootless container runs on a linux host, controlled by `systemctl --user ...`.
I have my finely crafted nftables ruleset that I want to keep. Docker is going to abuse the crap out of my ruleset/make me jump through extra hoops to have it work.
Having the containers operate under systemd looks fine (ignoring the fact that it is systemd, I guess I have finally accepted systemd is here to stay).
I was interested in using traefik & docker labelling to have ingress sorted out and I believe this will all play nicely enough to replace docker-compose on a single server.
You can also do 1 connection = 1 process, though, but it's absolutely not required nor particular common these days.
Then for deployment to a Kubernetes cluster you can reuse your podman kube yaml.
For deployment to a single machine where the full Kubernetes is overkill, you can use the podman quadlet support. Quadlets support a "[Kube]" section where you can point to the yaml file, so you don't have to write all your port and volume etc mappings again in a slightly different syntax.
Immediately after I finished the project I discovered the Quadlet thing!
Seems like the userbase is there, the technology is there, and now the two just need to be put together with some awareness.
The security aspect is something new to me and I'm not sure if that applies to inetd/systemd socket services or if it's specifically a container thing.
Does anyone have more info on use cases for this?
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.
It’s not a systemd-specific thing, but systemd makes it relatively easy to drop privileges (like network in this case), whilst also allowing socket-activated services to be configured easily. You can probably achieve the same thing with inetd + network namespaces (I think this is what systemd uses under the hood)
As for what can be so resource intensive that it's worth to wait for startup time instead of running everything at the same time - a bunch of specialized LLMs is the obvious example. Or maybe you're a hobbyist cramming a hundred services into a tiny computer.
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.
I wrote a demo: https://www.redhat.com/en/blog/podman-systemd-limit-access
Podman will then not have the privilege to pull the container image, but a web server container can still serve the internet with socket activation.
1. enable remote connection in podman desktop (https://podman-desktop.io/docs/podman/podman-remote)
2. try the quadlet extensions (https://podman-desktop.io/blog/podman-quadlet)
I am curious to have feedback if you give it a try (https://github.com/podman-desktop/extension-podman-quadlet/i...)
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.
It’s more useful for applications that keep open a connection for a while instead of stateless request/response architecture
Working for one myself, which does have a support contract wit Red Hat, I kinda get where they're coming from--if they make it easy to shoot yourself in the foot, dumb people shoot themselves in the foot in production and they have to fix the mess later. But for that they could have a sanctioned build for clients and a community build for everybody else, just like they have Fedora and RHEL.
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.
Containers: Encapsulate application and its environment
Pods: Group one or more containers in Kubernetes
Kubernetes: Orchestrates containers across clusters.
Quadlets: Declarative container management with Podman and systemd
Podlet: Tool to generate Quadlet file from existing podman configuration
Arguably worse, IMHO, is that the name lives on but does something wholly different, polluting search results
Anyway, I wanted to plug Flatcar which forked CoreOS back when the nonsense started and have been pretty pleasant to work with. They are still misguided about user-data management, and have since been acquired by Microsoft(!), but the code lives on https://github.com/flatcar/Flatcar#readme and https://www.flatcar.org/docs/latest#upgrading-from-coreos-co...
> Flatcar project repository for issue tracking, project documentation, etc.
Per the building page https://www.flatcar.org/docs/latest/reference/developer-guid...
the actual code seems to be at https://github.com/flatcar/scripts.git
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?
If you are a sysadmin / platform engineer / etc type familiar with kubernetes / k3s, podman has some pros and cons about it that make working in that ecosystem (systems, platforms) much nicer to manage.
What we are missing right now is a bridge between the two that podman-compose doesn't exactly fulfill for a lot of people.