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

161–170 of 250 posts

Re: Podman: A Daemonless Container Engine

#161

Post by SEJeff »

zapita wrote: post #147
kbenson wrote: post #135

Earlier quoted context omitted.

What was described could be the basis of a grudge, or it could be that Red Hat were convinced that the current project would not accept changes Red Hat would benefit by even if it helped many other people. At that point, and at the size of Red Hat and how important this technology is becoming for them, it only makes sense for them to secure some of the technological foundations they rely on. It costs them very little…

runc, containerd and the docker client are critical infrastructure to a whole lot of people, and they seem to be doing just fine running it and, when needed, contributing back. Only Red Hat seems to have a problem with using those projects without forking or re-writing them. Could it be because Red Hat considers it of strategic importance for their business, not just for those projects to be reliable (they are), but…

runc and containerd wouldn't exist if Redhat hadn't created the OCI specification and work around docker to make things interoperable. Docker, Inc was not playing ball and then redhat had to work around them. It wasn't a grudge it was just them keeping their business safe. The Open Containers Initiative was essentially designed to force Docker Inc to try to play better with others. They donated containerd to the OCI due to the reality that docker was about to be left in the dust.

For reference, this was the shirt that Docker Inc was giving away at Redhat summit years ago. I was there. I saw the shirt, and thought it was in very poor form. https://twitter.com/SEJeff/status/1125871424126767104

As Rambo said, "But Colonel, they drew first blood."

Re: Podman: A Daemonless Container Engine

#162

Post by qbasic_forever »

nednar wrote: post #150
yobert wrote: post #109

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 the…

What are the Github issue IDs for these 4 problems?

Where are the four unit tests in podman's codebase that should be catching these issues?

I find it very strange that your reaction is, "the software is infallible, it is _YOU_ who have failed the software by not logging bugs!" It is perfectly reasonable to have a conversation about the quality or issues with a piece of software SEPARATE TO the logging or finding of bugs in said software.

Re: Podman: A Daemonless Container Engine

#163

Post by speedgoose »

coldtea wrote: post #146
lima wrote: post #90

Earlier quoted context omitted.

Better, yes. Safe, no. Even with ASAN and modern C++, vulnerabilities happen all the time.

And yet NASA uses C, not Rust.

I don't think you want to develop your software project like the NASA develops its critical software projects.

Re: Podman: A Daemonless Container Engine

#164

Post by zapita »

SEJeff wrote: post #161
zapita wrote: post #147

Earlier quoted context omitted.

runc, containerd and the docker client are critical infrastructure to a whole lot of people, and they seem to be doing just fine running it and, when needed, contributing back. Only Red Hat seems to have a problem with using those projects without forking or re-writing them. Could it be because Red Hat considers it of strategic importance for their business, not just for those projects to be reliable (they are), but…

runc and containerd wouldn't exist if Redhat hadn't created the OCI specification and work around docker to make things interoperable. Docker, Inc was not playing ball and then redhat had to work around them. It wasn't a grudge it was just them keeping their business safe. The Open Containers Initiative was essentially designed to force Docker Inc to try to play better with others. They donated containerd to the OCI…

Your history is wrong. Docker created the OCI, not Red Hat. Docker donated both the spec and the runc implementation.

Containerd was donated (also by Docker) to CNCF, a different organization, and I believe a few years later.

You are correct that Docker did those things because of pressure to be more interoperable.

Reading your linked tweet (“don’t mess with an engineering behemoth”) you seem to agree that Red Hat is rewriting away Docker code because of a past grudge?

Re: Podman: A Daemonless Container Engine

#165

Post by zapita »

tpush wrote: post #158
zapita wrote: post #148

Earlier quoted context omitted.

Excellent question, especially since the code is copy-pasted without crediting the original authors. Could it be that they’re trying to minimize the role of Docker as much as possible even when re-using their code?

> Excellent question, especially since the code is copy-pasted without crediting the original authors. That seems like a serious allegation. Can you back that up?

It’s right there in the repo history. Start from the first commits. I don’t know how serious of an allegation it is: copy-pasting open-source code without crediting it properly is rude, but not illegal.

Re: Podman: A Daemonless Container Engine

#166

Post by Klasiaster »

rq1 wrote: post #79

What’s the difference with systemd-nspawn? (with or without -U)

Podman can run under your user and use your UID (e.g., 1000) as UID 0 for the root user in the container. Any other user in the container gets mapped to a temporary unprivileged UID on your system (the range to pick from is specified in /etc/subuid).

Re: Podman: A Daemonless Container Engine

#167

Post by xerxes901 »

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.

I did some hacking on crun this week to fix a bug, so maybe I can offer a perspective about why it’s written in C.

A huge part of a container runtime is pretty much just issuing Linux syscalls - and often the new ones too, that don’t have any glibc bindings yet and need to be called by number. Plus, very careful control of threading is needed, and it’s not just a case of calling runtime.LockOSThread() in go - some of these namespace related syscalls can only be called if there is a single thread in the process.

It’s _possible_ to do this in go, of course; runc exists after all. But it’s certainly very convenient to be able to flip back and forth between kernel source and the crun code base, to use exactly the actual structs that are defined in the kernel headers, and to generally be using the lingua franca of interfacing with the Linux kernel. It lowers cognitive overhead (eg what is the runtime going to do here?) and lets you focus on making exactly the calls to the kernel that you want.

Re: Podman: A Daemonless Container Engine

#168

Post by eriksjolund »

edwintorok wrote: post #4
zeroxfe wrote: 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…

If I understand correctly support for native rootless mounts is currently under development: https://github.com/containers/storage/pull/816 The functionality requires Linux kernel 5.11 (soon to be released)

Re: Podman: A Daemonless Container Engine

#169

Post by nednar »

bartvk wrote: post #156
nednar wrote: post #150

Earlier quoted context omitted.

What are the Github issue IDs for these 4 problems?

What are you trying to say here? Your comment feels a bit passive-aggressive.

> What are you trying to say here?

I want to look at the problems. But I don't want to do a guessing game with the 159 open issues, which one may relate to one of these points or not.

Re: Podman: A Daemonless Container Engine

#170

Post by doliveira »

archi42 wrote: post #106
eeZah7Ux wrote: post #96

Earlier quoted context omitted.

> 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.…

Developing anything without root in your own machine these days must be an absolute nightmare. If I may ask, what stack are you using? I can imagine Java, but that's about it. Go, Python, Node, etc, all of them I've needed root access to test some packages, for instance.

I would guess developers must be using a lot of "workarounds" without management's knowledge.

Post reply on HN