Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Podman: A Daemonless Container Engine

podman.io

Post reply on HN
Print view View original

71–80 of 250 posts

Re: Podman: A Daemonless Container Engine

#71

Post by feanaro »

shaicoleman wrote: post #59
zeroxfe wrote: post #2

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

I tried it, and went back to Docker with BuildKit. * The newer version of Docker+BulidKit supports bind-mounts/caching/secrets/memory filesystem etc. we used it to significantly speed up builds. You could probably find a way in buildah to achieve the same things, but it's not standard. * Parallel builds - Docker+BulidKit builds Dockerfile in parallel, in podman things run serially. The combination of caching and para…

FWIW, I'm using Podman and I'm happy with it given that it's fast enough for my purposes and I haven't encountered any caching bugs.

Re: Podman: A Daemonless Container Engine

#72

Post by coder543 »

lima wrote: post #70
SEJeff wrote: post #41

Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster: https://github.com/containers/crun

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

Yeah. I just don’t think “runc” has ever been a bottleneck in any systems I’ve worked with.

It’s been years since I’ve been able to get excited about rewriting systems from a memory safe language into a memory unsafe language for “performance reasons”. As an industry, we have too much evidence that even the best humans make mistakes. Quality C codebases still consistently run into CVEs that a memory safe language would have prevented.

Rust exists, if performance is so critical here and if Go were somehow at fault... but it sounds like most of the performance difference is due to a different architecture, so rewriting runc in Go probably could have had the same outcome.

I wish I could be excited about crun... I’m sure the author has put a lot of effort into it. Instead, I’m more excited about things like Firecracker or gVisor that enable people to further isolate containers, even though such a thing naturally comes with some performance impact.

Re: Podman: A Daemonless Container Engine

#74

Post by curt15 »

The ability to start containers as a normal user ("rootless mode") is quite interesting and imo the most significant feature missing from LXD, which requires you to either use sudo or be a part of the "lxc" group (equivalent to having sudo privileges).

Re: Podman: A Daemonless Container Engine

#75

Post by lima »

coder543 wrote: post #72
lima wrote: post #70

Earlier quoted context omitted.

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

Yeah. I just don’t think “runc” has ever been a bottleneck in any systems I’ve worked with. It’s been years since I’ve been able to get excited about rewriting systems from a memory safe language into a memory unsafe language for “performance reasons”. As an industry, we have too much evidence that even the best humans make mistakes. Quality C codebases still consistently run into CVEs that a memory safe language wou…

> I wish I could be excited about crun... I’m sure the author has put a lot of effort into it. Instead, I’m more excited about things like Firecracker that attempt to enable people to further isolate containers, even though such a thing naturally comes with some performance impact.

gVisor is also very exciting due to how it handles memory allocation and scheduling. Syscalls and I/O are more expensive, though.

Re: Podman: A Daemonless Container Engine

#77

Post by dnautics »

zeroxfe wrote: post #2

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

I've been using my company's docker compose script transparently with podman-compose for three months now and I have basically forgotten that I've switched. I actually didn't use docker before this, so I can't comment on what the difference is.

I feel like the podman experience is binary, either it works perfectly or it sucks balls. My suggestion is to give it a try, if it fails, then maybe file a bug report, fail fast and fall back on docker.

Re: Podman: A Daemonless Container Engine

#78

Post by coder543 »

lima wrote: post #75
coder543 wrote: post #72

Earlier quoted context omitted.

Yeah. I just don’t think “runc” has ever been a bottleneck in any systems I’ve worked with. It’s been years since I’ve been able to get excited about rewriting systems from a memory safe language into a memory unsafe language for “performance reasons”. As an industry, we have too much evidence that even the best humans make mistakes. Quality C codebases still consistently run into CVEs that a memory safe language wou…

> I wish I could be excited about crun... I’m sure the author has put a lot of effort into it. Instead, I’m more excited about things like Firecracker that attempt to enable people to further isolate containers, even though such a thing naturally comes with some performance impact. gVisor is also very exciting due to how it handles memory allocation and scheduling. Syscalls and I/O are more expensive, though.

Heh, I actually edited gVisor in right before your reply.

I agree completely!

Re: Podman: A Daemonless Container Engine

#80

Post by dnautics »

igneo676 wrote: post #43
zeroxfe wrote: post #2

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

I had pretty negative experiences with it. I'm not sure how much of my experience is _actually_ the fault of Podman and how much of it was around using it as a drop-in replacement for Docker. It baffled me though and I'm a long time Docker and Linux user. I used Arch Linux and followed their docs[1], mainly because I wanted it to also run without root. Big mistake. Attempting to run a simple postgres database w/ and…

I don't know when you tried this but I recall it having sucked in the summer when I tried it and I gave up. New job in the fall, decided to give podman a shot "if it doesn't work on the first try I'm going to use docker", then podman-compose 3rd party instructions (I can't remember which) just works out of the box. I'm running a fleet that includes postgres and redis.
Post reply on HN