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

101–110 of 250 posts

Re: Podman: A Daemonless Container Engine

#101

Post by SEJeff »

vishvananda wrote: post #95
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.

Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0], so it has to be done in C before the go runtime initializes. I do think rust is a better choice for this layer than C because there are still security risks, but getting rid of Go for this layer is a win. I'm not sure why RH chose to rewrite it in C rather than using rust[1]. [0…

This I entirely agree with you on but I’d expect it due to the resources available at the time were more fluent with C than rust. A shame really.

Re: Podman: A Daemonless Container Engine

#102

Post by perlgeek »

Spivak wrote: post #88
perlgeek wrote: post #45

Earlier quoted context omitted.

One huge advantage over docker is that if you mount a directory into the container, and the container writes files there, on the host system they always have the owner of the user that started the container. That makes it much more convenient for build environments, without having to hard-code user IDs both in the container and on the host.

If you're on a Linux system you can actually make this work better with sssd. So sssd's architecture is actually client-server over a unix socket. So all you need to do is create a very simple base container layer that just installs sssd-client, and wires up /etc/nsswitch.conf to use it (your package manager will almost surely do this automatically). Then just bind mount the sssd socket into your container and boom,…

Sounds interesting, do you have a link to an example where this is done/demonstrated?

(Also I'm not sure how that's better (and not just different), except maybe it allows more than one host user in the container, but I haven't had a use case for that).

Re: Podman: A Daemonless Container Engine

#104

Post by [deleted] »

vishvananda wrote: post #95
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.

Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0], so it has to be done in C before the go runtime initializes. I do think rust is a better choice for this layer than C because there are still security risks, but getting rid of Go for this layer is a win. I'm not sure why RH chose to rewrite it in C rather than using rust[1]. [0…

[deleted]

Re: Podman: A Daemonless Container Engine

#105

Post by zapita »

SEJeff wrote: post #100
zapita wrote: post #92

Earlier quoted context omitted.

It’s not for performance. It’s to settle an old grudge with Docker. All code coming from Docker must be erased. See also: podman; cri-o; buildah.

Grudge? You mean when Jessie Frazelle walked around dockercon with a badge saying, “I will not merge patches for systemd” just out of principal? In hindsight it is fairly obvious picking a fight at redhat summit was a very poor long term strategy from docker. It forced them to ultimately sell the orchestration parts of their business and massively limit the free tier of docker hub.

Thank you for illustrating my point perfectly.

“Grudge?” (proceeds with details of grudge).

Re: Podman: A Daemonless Container Engine

#106

Post by archi42 »

eeZah7Ux wrote: post #96
archi42 wrote: post #82

Earlier quoted context omitted.

This. SO MUCH THIS. We use docker for our CI, which is mostly okay. But we devs don't have root on our workstations, so we can't just load the docker image and test stuff in the CI env. Enter podman: I've written a small perl wrapper around it and now everyone can just call `ci-chroot` to drop to a CI-equivalent shell. They can get virtual root (default) or normal user (--user), and the script takes care of everythin…

> we devs don't have root on our workstations What's the justification for this... while at the same time allowing the use of containers?

With root it's easy to mess up the system badly ("I'll just fix that small error") and/or let all systems slowly diverge. And if something fails on my workstation, it will fail on many others as well and needs a coordinated solution. Also, giving every dev root is a security liability, especially when there is absolutely no work reason that requires us to become root. So only a few "core IT" people have root access.

I don't see how that contradicts the use of containers? When we only used docker for the CI we didn't have access to them, because escalating to root from within docker is still pretty easy. But with podman they're running with our privileges (and due to gid/uid mapping, I can run our installer "as root" in the container and see if it sets up everthing correctly - while in reality the process runs under my uid).

Disclaimer: This is in a professional enviroment. At home I despise containers and prefer to have all my service installed and easily updated by the system's package manager.

Re: Podman: A Daemonless Container Engine

#107

Post by kohlerm »

eeZah7Ux wrote: post #96
archi42 wrote: post #82

Earlier quoted context omitted.

This. SO MUCH THIS. We use docker for our CI, which is mostly okay. But we devs don't have root on our workstations, so we can't just load the docker image and test stuff in the CI env. Enter podman: I've written a small perl wrapper around it and now everyone can just call `ci-chroot` to drop to a CI-equivalent shell. They can get virtual root (default) or normal user (--user), and the script takes care of everythin…

> we devs don't have root on our workstations What's the justification for this... while at the same time allowing the use of containers?

In big companies there isn't always a good justification for a restriction ;-)

Re: Podman: A Daemonless Container Engine

#109

Post by yobert »

I've been trying to use podman in production and it is not working very well. I'm excited for this technology but it is not ready.

- podman layer caching during builds do not work. When we switched back to docker-ce, builds went from 45 minutes to 3 minutes with no changes to our Dockerfile

- fuse-overlayfs sits at 100% CPU all day, every day on our production servers

- podman loses track of containers. Sometimes they are running but don't show in podman ps

- sometimes podman just gets stuck and can't prune or stop a container

(edit: formatting)

Post reply on HN