Hacker News Reader

Comment by indigo945 | Hacker News Reader

Podman is probably close to what you want. It runs "daemonless" - while no containers are running, podman doesn't have a running process either. Also, as long as the containers are run in rootless mode, podman creates no virtual network interfaces. Rootless Podman makes use of network namespaces instead to separate the processes in the container from the host network. Processes on the host cannot see Podman's network namespaces and therefore are completely unaffected by any IP configuration therein.

View on HN

This;

Podman is what Docker should have been, for me. Security first, no daemon, more Linux-like behavior (You can manage them with SystemD unit files if you wish) and it supports the same, usual container images you build/use with Docker.

The main part it was lacking is the compose equivalent, but that too is coming along.

Honestly with quadlet it might be there on the compose front: being able to deploy either as systemd-like files or as Kubernetes manifests probably solves the entire problem in a very nice way (the K8S compatibility is the real magic IMO since it's the defacto cloud ecosystem).

I haven't played with any of Podman's Kubernetes YAML stuff yet, but we target Kubernetes.

Does it support higher-level declarations like Deployments and StatefulSets? I'm trying to understand how/if we could use this without having to write new manifests. A (very) quick search didn't clarify it for me.

Quadlets just create a systemd unit file to launch containers with podman and have systemd manage its lifetime. Since systemd lacks the ability of controllers like Deployment and StatefulSets, I doubt that quadlets are able to achieve much more.

I'm pretty sure, that cleverly combining various unit types and their capabilities/attributes would allow to cover 90% of what's needed to emulate Deployments and StatefulSets.

Yes. That's what I assume too.

Is it coming along? Last I saw they were moving away from the compose Schema to a k8s manifest and... Those are absolutely disgusting.

You can use docker-compose with podman using podman's docker compatibility API.

See my other comment in a recent thread [0]

[0] : https://news.ycombinator.com/item?id=37661056

(It's fun to note how systemd was an epitome of in-Linux-like software 7-8 years ago, and now it's the opposite. I'm not talking about systemd merits here, just about the change in perception.)

Comparably little harsh criticism has been made for systemd the init system, most has concerned systemd-the-almost-ntp-client and systemd-the-binary-logfile, the various related xml documents, things like that.

From my understanding, it has serious limitations, for example since it's rootless, it can't bind on port 443

I find Podman frustrating at times because of how strict is with ACLs, UID maps and its integrations with SELINUX. I've had a chown/chmod -R of my own home folder (for migration purposes) cripple all podman (AND toolbox) related stuff for my user.

All in all its a great program and IMO even better than docker but It would be great if people try to make it sound like its a 1:1 comparison to Docker because it has its trade offs.

Security is a pain, however cleaning up after the fact is even worse.

I would argue that the selinux and uid issues with podman are selinux and posix DAC’s fault.

Selinux is neat but is IMO conceptually wrong in a container world. UIDs and are barely better. At most, these mechanisms should confirm that the container as a whole has a given permission, and that’s it.

(Seriously, the major clouds have deprecated per-object permissions on their object stores. IMO they are right to have done so.)

It might feel frustrating, but there is a great reason. It gives you a more secure environment. When Docker just "works", you are unaware of the fact that you have given more permissions than app might actually need, increasing the attack vector.

Podman's use of SELinux prevents and mitigates many of these issues what you will have if somone targets your app.

To be honest I never even tried out Podman, even though I keep reading positive things about it. But the entire Docker ecosystem is complex enough on its own, so I fear that exchanging the container runtime entirely will cause a lot of problems that I don't know about today.

Podman has docker-compatible CLI, Dockerfiles and even docker-compose compatibility. It won't be as painful as you worry. So just give it a try. And besides the advantages already mentioned (rootless, no-daemon and isolated network namespaces), podman has some additional nifty features like pods (like in K8s), quadlets (containers managed by systemd), compatibility with k8s manifests, etc.

undeniable that you'll have a thing or two pop up—whether or not it's worth it depends on how much you want to understand. despite differences in how it works, podman _is_ simpler.

the reality though is that you can install both docker and podman, and just start/stop docker as necessary. its easy enough to experiment with podman on a system with docker installed.

imo it's similar to folks that think learning a new shell is a huge undertaking. the reality is you just install the new thing and drop in and out of it as you get comfortable. if it sticks, cool, if not, also cool.

you can also use docker rootless if you want that style of networking. Indeed AFAIK docker and podman rootless both use the same networking approach (slirp4netns)

You can use pasta mode for rootless https://docs.podman.io/en/latest/markdown/podman-run.1.html#...

Isn’t podman just IBMs version of docker?

Reply on news.ycombinator.com