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

151–160 of 250 posts

Re: Podman: A Daemonless Container Engine

#151

Post by tw04 »

yobert wrote: post #112
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…

Reading through the comments though it looks like I should try making a BTRFS mount for the container storage and that might help the fuse-overlayfs problems though.

I know it tends to be a controversial technology around here, but I've had great luck with OpenZFS for container storage.

Re: Podman: A Daemonless Container Engine

#152

Post by kbenson »

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…

That could be, but if Frazelle did actually walk around with a button saying “I will not merge patches for systemd” I think it's simpler and safer to assume Red Hat decided that relying on Docker was risky given how important it was to their future products and the apparent animus on display from the Docker maintainer.

If I carpool with someone and they like to go around and loudly proclaim "I refuse to listen to anything kbenson has to say", maybe I find someone else to carpool with or drive myself? That only seems prudent. That doesn't mean I have a grudge against that person, it just means I don't want to trust them with getting me to and from work anymore.

Re: Podman: A Daemonless Container Engine

#153

Post by [deleted] »

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.

[deleted]

Re: Podman: A Daemonless Container Engine

#155

Post by mixmastamyk »

curt15 wrote: post #74

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

Wouldn't the lxc group have much more focused permissions than sudo?

Re: Podman: A Daemonless Container Engine

#156

Post by bartvk »

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?

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

Re: Podman: A Daemonless Container Engine

#157

Post by AlphaSite »

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

Why does it matter what happens to your machine?

The big corp I work for has no issue with any of this so I genuinely don’t understand the motivation for this restriction.

Your machine shouldn’t have anything important on it and if it does I’m not sure that root/non-root will protect you from that.

Re: Podman: A Daemonless Container Engine

#158

Post by tpush »

zapita wrote: post #148
hda111 wrote: post #140

Earlier quoted context omitted.

So why does podman include code from docker?

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?

Re: Podman: A Daemonless Container Engine

#159

Post by zapita »

kbenson wrote: post #152
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…

That could be, but if Frazelle did actually walk around with a button saying “I will not merge patches for systemd” I think it's simpler and safer to assume Red Hat decided that relying on Docker was risky given how important it was to their future products and the apparent animus on display from the Docker maintainer. If I carpool with someone and they like to go around and loudly proclaim "I refuse to listen to any…

It’s no secret that there were tensions betwen Docker and Red Hat that culminated around 2016, when Red Hat’s desire to capitalize on the success of containers ran into Docker’s own ambitions to compete with Red Hat. Those tensions were eventually resolved (or at least diminished) by Red Hat shifting gears to Kubernetes as their “next Linux”.

The drama you’re talking about is from that period - 2015-16. But “crun” was launched in 2020, a full four years later. Frazelle left Docker years ago, as well as most of the people involved in those feuds. Runc, containerd and docker are chugging along drama-free, and are maintained by multi-vendor teams. There is no interest from anyone outside of Red Hat in forking or re-writing those tools. It’s just a tremendous waste of energy and in the end will be problematic for Red Hat, because they will be building their platform on less used and therefore less reliable code.

The world’s container infrastructure runs on containerd, runc and docker. Not crio, crun and podman. Someone at Red Hat clearly is having trouble accepting that reality, in my opinion because they’re having trouble moving on from old grudges. I really wish they did, because all of that wasted engineering effort could be deployed to solve more pressing problems.

Re: Podman: A Daemonless Container Engine

#160

Post by johnchristopher »

maweki wrote: post #138

One very interesting piece of tech coming from it, is toolbox ( https://github.com/containers/toolbox ). Basically throwaway (or keeparound) rootless containers with their own root directory but shared HOME. Install hundreds of dev-dependencies to build this one piece of software? Yeah, not gonna install those packages permanently. Spin up a toolbox, build it, install it in my home/.local. You have root in the contai…

I usually share a volume between containers (eg:: a volume for wp-cli cache, another for -g npm_modules).

What benefits would toolbox add ?

Post reply on HN