Say what you want about docker compose, but when I see the amount of scaffolding necessary for this, with so many catch words like butane or ignition, I’m happy with my good ol’ docker composé file where everything is neatly organized. In one glance I can see what is deployed, depends on what and what net / volume is used.
I was confused by this article in the beginning, it does a pretty bad job at drawing a distinction between the pure quadlet example at the start and the example of using CoreOS to build and launch a VM that starts containers.
The basic usage of podman quadlets is putting an `app.container` in `/etc/containers/systemd/` containing something like the first snippet and then starting the unit. For someone familiar with systemd, this seems very very nice to work with.
I'm still not clear whether quadlets are a feature of Podman or systemd...
The reliance on systemd is an issue on its own. Much has been said about its intrusion in all aspects of Linux, and I still prefer using distros without it. How can I use this on, say, Void Linux? Standalone Podman does work there, but I'm not familiar if there were some hacks needed to make it work with runit, and if more would be needed for this quadlet feature.
I mean the best part about open source and Linux is that you have choice. Do you want to run an OS devoid of SystemD? Fine. Will you be going against the tide and leaving a large part of the ecosystem behind? Yup.
I’ve chosen to embrace systemd and learn it as it is the defacto standard it seems rather than fight what I think is a futile war against it. That being said. I won’t force you to use it if you don’t. But I do not see quadlets using systemd as a failing.
This is such a bizarre comment. I run systemd a number of Linux machines currently but does that mean they are failing? Is taking advantage of systemd's features a failure? They run and do their function so in what sense are they failing or what does failure mean?
By my calculations, considering much of the world runs on RH/Ubuntu/Debian, all of which use systemd, things depending on systemd are far from being a failure, cos they'll run on the majority of systems.
"quadlets" are podman using systemd's extension mechanism [systemd.generator(7)] to create systemd services that invoke podman to run containers, based on the files you drop into /etc/containers/systemd.
Yes! Can we talk about projects consistently deciding to invent new nomenclature for their entities or products. Is it an effort to lock you in to their system?
It is not entirely obvious - can I use quadlets in an ad-hoc fashion to spin up a project? The example makes it seem like it is exclusively for long running services.
I also miss the simplicity of compose, but for me running rootless is worth the tradeoff. It also forced me to rethink how I used containers and I realized many times a simple podman_run.sh is enough. It also helped me understand containers better because there was less magic going on, sometimes limitations can be good.
> I also miss the simplicity of compose, but for me running rootless is worth the tradeoff.
To setup/tear down software dev environments deployed locally, the root/rootless discussion isn't really relevant. Ease of deployment and ease of use are critical though, and Docker is above all a development experience victory.
Relevant to who? The damage done with container escape is bigger on my machine than any production server I have access to. And there are a lot more packages running in my dev environment than on production servers. When it comes to security or convenience I always choose the first but I know most people wont.
Podman-compose isn't as good as docker but it exists, and you can run docker-compose with podman as the runtime. I don't need it as my environments are simple and even wrapping the commands in shell scripts would be overkill. But the option is there.
> The damage done with container escape is bigger on my machine than any production server I have access to.
It's worth pointing out that if you're running on Fedora/RHEL then containers are confined to the container_t domain, with a unit per-container MCS label. SELinux policy will prevent a process that has broken out of its namespaces from being able to read/write files from the host or from other containers, or being able to kill or read the memory of or (I'm assuming, haven't checked) ptrace processes from the host or other containers.
> Relevant to who? The damage done with container escape is bigger on my machine than any production server I have access to.
If you are concerned that your dev machine is vulnerable but for any reason you decided to not do anything about it, them you might be happy to learn that it's possible to configure Docker to not run as root.
> If you are concerned that your dev machine is vulnerable but for any reason you decided to not do anything about it
Why would you assume I'm not doing anything about it? Podman is one piece in my hygiene, not allowing npm scripts is another. It does make some things harder and most devs I work with don't even know it's possible and should be done. Assuming you aren't vulnerable and waiting for a problem to appear before solving it is doing it backwards if you ask me. Your kind of self-confidence is what usually gets people.
I could also point docker-compose to the podman socket (it's the default for the podman compose command), if that was something I needed. Pods do it for me these days, which was my initial point. Even though compose is cool it's not really needed and wouldn't add that much for me these days. I've been using podman so long that I don't see the point in going back to docker, changing the default when what I'm using was built to fix that issue to begin with.
What point are you trying to make? I can live without docker.
FWIW podman 4's netavark has solved most of the pain points I encountered with podman's rootless networking. Containers can actually find each other now.
For simple projects, it’s hard to beat