Quadlet is one of the best things to have come out of Podman and I highly recommend anyone curious about Podman or switch to container-based workloads to check them out. Being able to slot containers in and treat them like essentially any other system service feels great, plus I don't have to learn some extra orchestration layer to get them to work together or depend on non-container resources. I can just write the same systemd units I'm already writing. The auto-updating and service restart/notify on failure/etc is just icing on the cake. I've seen the equivalent Docker versions before and they're awful; giant messy run commands to try to work around the Docker daemon and half the time you end up with phantom services and containers anyway. Quadlet's end up being much cleaner; plus it means your whole setup (besides volume contents) exists with your other systemd units (/etc/systemd/, .config/systemd, /usr/local/lib/systemd, etc) so it's easy for backups.
The only downside is they're not really an answer to docker-compose on the local development side and the podman team doesn't seem super interested in tackling that segment. User containers are nice for long running local test infra (i.e. a background database) but are too clunky for a normal compile-> docker compose up -> test -> docker compose down loop. The best answer is either .kube Quadlets (kubernetes plays) or using docker compose [0] against the podman socket.
Either way, I've enjoyed using quadlets enough that I've spent the last few months writing a gitops tool for managing them in my spare time. They just feel like the right way of managing containerized servers.
[0] NOT podman-compose, which the article points out as being not very good and under-developed. Podman implements most of the compose spec so you can use docker compose for most situations. I suspect many people who tried Podman when RH first started pushing it ran into Podman 3 being kinda of bleh and podman-compose being awful and bounced off it.
I wanted to use quadlets and tried podlets as well since I wanted to try staying close to the RH paradigm. The experience coming from docker compose (on top of podman) was horrendous. It became a rabbit hole of trying with different flags, upgrading versions, following suggestions from podlet itself to switch to another tool, etc.
Ultimately my systemd just executes `podman compose up`.
What are the benefits of quadlets as opposed to letting compose do its job?
Update: podman runs under my user, no demon whatsoever.
Not sure I follow; you don't need to use podlet at all unless you're migrating from existing compose files and want some help. I don't use it outside of a few one-offs. If you're referring to "pods" as in the kubernetes-style container orchestration, than you don't have to use those either. Did you happen to try this on Ubuntu/Debian? Both distros tend to have very old versions of Podman in the repos. TBH podman was not worth using before 4.2 or so, no matter what Red Hat said. I'm not sure I'm following your situation/ use-case though.
If you're already running podman containers as systemd units, then the main benefit would probably be better systemd integration and without having to write separate compose files. If you're fine with the latter than A) you're the only person I've met who's happy with podman compose and B) you probably won't gain that much from switching to quadlets. Out of curiosity, does systemd spinning up podman-compose still properly keep the resulting container processes in the same cgroup? If not, that would be a decent benefit to swapping to quadlets.
I am coming from docker files which give me a concise view of what services I’m configuring and how. The process of converting these tools into a (bunch of?) quadlets is where I got stuck.
As far as I could see at the time all containers in one compose file ended up in the same cgroup.
I’m not using podman compose but docker compose over the socket created by podman.
It integrates naturally into my desktop environment.
I drop a .container file into ~/.config/containers/systemd/ and the rest is taken care of. I use yadm to manage my dot files and that way it ends up on all the systems I want it.
Never tried podlet, though. I just write the container file directly.
I've been looking for a better solution for local dev on services deployed via quadlet, could you elaborate on this?
I just took a look at the socket activation docs[0]. Is my understanding correct that no `compose.yaml` is required, just running `docker-compose up` with the appropriate env var pointing to the socket is enough to trigger a connection and service activation?
As far as I remember my podman installations on both fedora and ubuntu came with a podman.socket service that I could enable as easily as running:
`systemctl --user enable --now podman.socket`
It works perfectly fine if you install docker but just the CLI (e.g. on debian docker provides a package for that in their deb repository).
Then you can use docker contexts to make the default context your podman socket. Then you just use `docker compose` as you normally would. I usually use this with rootless podman installs.
The only downside is they're not really an answer to docker-compose on the local development side and the podman team doesn't seem super interested in tackling that segment. User containers are nice for long running local test infra (i.e. a background database) but are too clunky for a normal compile-> docker compose up -> test -> docker compose down loop. The best answer is either .kube Quadlets (kubernetes plays) or using docker compose [0] against the podman socket.
Either way, I've enjoyed using quadlets enough that I've spent the last few months writing a gitops tool for managing them in my spare time. They just feel like the right way of managing containerized servers.
[0] NOT podman-compose, which the article points out as being not very good and under-developed. Podman implements most of the compose spec so you can use docker compose for most situations. I suspect many people who tried Podman when RH first started pushing it ran into Podman 3 being kinda of bleh and podman-compose being awful and bounced off it.