Live data from Hacker News

Podman: A Daemonless Container Engine

podman.io

21–30 of 250 posts

Re: Podman: A Daemonless Container Engine

#21
post #5

I liked podman for what I was working on with it. The only hangup I found was that it couldn't do networking related routing? Does anyone know more?

As far as I know it can do so but not when running rootless, I also don't thing it's currently possible to be done rootless.

You still can run podman as root without damon.

Or you can run a podman deamon (through systemd) which is even compatible with docker-compose but has most of the drawbacks of running docker.

Re: Podman: A Daemonless Container Engine

#24
post #2

Anyone have experience with this? I love the idea of it being daemonless.

Out of curiosity, why do you prefer daemonless setups?

If I have 30 containers running, why should a single daemon being restarted cause all 30 to shutdown as well?

Similarly, the docker security model is that there isn't a security model. If you can talk to the docker socket you have what ever privileges the daemon is running as.

Re: Podman: A Daemonless Container Engine

#25

What's the status on ease of running on Mac? I know last time I seriously considered testing it out in my workflow, it was kind of crazy that I had to have a separate machine (VM or real) just to run container images... I see in the docs [1]: "Podman is a tool for running Linux containers. You can do this from a MacOS desktop as long as you have access to a linux box either running inside of a VM on the host, or avai…

The docker machine or whatever it’s called these days is pretty impressive but when we’ve tried to use it in developer workflows on mac it would eat all of the CPU allotted to it in order to marshal filesystem events over the host/guest VM boundary. We tried a number of workarounds but none solved the problem. I’m sure it’s possible, but we ultimately gave up and moved back to developing against native processes on MacOS.

For other use cases I imagine it’s just fine.

Re: Podman: A Daemonless Container Engine

#26
post #24

Earlier quoted context omitted.

Out of curiosity, why do you prefer daemonless setups?

If I have 30 containers running, why should a single daemon being restarted cause all 30 to shutdown as well? Similarly, the docker security model is that there isn't a security model. If you can talk to the docker socket you have what ever privileges the daemon is running as.

So Docker supports live restore https://docs.docker.com/config/containers/live-restore/ which addresses the first point.

Second point, yep if you run Docker as root and someone can access the socket file they get root.

If that's a concern, you can run Docker rootless.

And as we're talking file permissions on a local host to allow that access, the same applies to podman containers does it not? If there are permission issues allowing another user to use access the container filesystems, you have the same problem.

Re: Podman: A Daemonless Container Engine

#27

Happy to see docker alternative, but the road is still long for it to replace docker

I don't think so.

It's doing a better job for most of the use cases I had recently.

You can run it rootless which makes it a far better use cases for a lot of dev use cases (where you don't need to emulate a lot of network aspects or heavy filesystem usage).

Also you can run it as root without deamon which is much better for a bunch of use cases and eliminates any problems with fuse-overlayfs. This is the best way to e.g. containerize systemd services and similar (and security wise still better as e.g. it still works well with the audit subsystem).

If worse comes to worse you can run it as a deamon in which case it's compatible with docker compose, and has more or less the same problems.

In my experience besides some integration testing use-cases is either already a good docker replacement without running it as a deamon, or the use case shouldn't be handled by docker either way (sure there are always some exceptions).

Lastly I had far less problems with podman and firewalls then with docker but I haven't looked into why that's the case. (But it seems to be related to me using nftables instead of iptables).

Re: Podman: A Daemonless Container Engine

#28

What's the status on ease of running on Mac? I know last time I seriously considered testing it out in my workflow, it was kind of crazy that I had to have a separate machine (VM or real) just to run container images... I see in the docs [1]: "Podman is a tool for running Linux containers. You can do this from a MacOS desktop as long as you have access to a linux box either running inside of a VM on the host, or avai…

The docker machine or whatever it’s called these days is pretty impressive but when we’ve tried to use it in developer workflows on mac it would eat all of the CPU allotted to it in order to marshal filesystem events over the host/guest VM boundary. We tried a number of workarounds but none solved the problem. I’m sure it’s possible, but we ultimately gave up and moved back to developing against native processes on M…

this is an issue I have battled as well. Docker is great for normalizing the execution environment; which should be a huge boon for developer tooling but on MacOS having your laptop sound like a hovercraft just to have some files watched for hot rebuilds is no bueno.

Re: Podman: A Daemonless Container Engine

#29
post #2

Anyone have experience with this? I love the idea of it being daemonless.

Out of curiosity, why do you prefer daemonless setups?

When you use a system-level daemon[0], the daemon has to have privileges to start a container as anyone (that is... root). In a daemon-less environment, you only need the privileges of the user who is starting the container.

[0] I suppose you could have a user-level daemon that runs for each user that needs to run containers, but that's even more overhead.

Re: Podman: A Daemonless Container Engine

#30
post #2

Anyone have experience with this? I love the idea of it being daemonless.

If you run it as non-root it is significantly slower than docker as root. Docker can us the overlay2 kernel driver, whereas podkan would use fuse-overlayfs in userspace. This has a high CPU overhead (e.g. don't try to run AFL inside podman), and a 1024 FD limit for the entire container (so a 'make -j40' usually dies). There are ways around it: raise the ulimit for your user and run new enough podman to raise limit fo…

Are these fuse limitations or fuse-overlayfs limitations ?
Post reply on HN