top | item 42139044

Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

272 points| twelvenmonkeys | 1 year ago |redhat.com

82 comments

order

kuratkull|1 year ago

Podman actually works really well. Out-of-the-box virtually-no-configuration-needed rootless containers. It's also usable via docker-compose with a single env variable. (podman-compose wasn't up to par for us)

We've been using it for a couple of years running and managing hundreds of containers per server - no feeling of flakiness whatsoever. It's virtually zeroconf and even supports GPUs for those who need it. It's like docker but better, IMO.

Hope it gets a popularity boost from CNCF. Rooting for it.

zamalek|1 year ago

I vastly prefer it to Docker, especially buildah over buildx. Instead of inventing yet-another-dsl buildah allows you to simply use shell scripts (though it does also support dockerfiles). Another thing buildah is really good at is not doing much automatically: you can really optimize layers if you care to.

The Podman ecosystem has given me a strong disliking of the Docker ecosystem, so I'm also rooting for it.

papichulo2023|1 year ago

I only dislike Podman because some distributions used it as an alias for docker which made a lot of docker-compatible software to not work on that distribution unless some workarounds. I wouldnt normally blame the application for this but in this case they are both, application and distribution, from the same dev.

jeppester|1 year ago

I completely agree and have had the same experience as you with docker-compose working better than the alternatives.

Past versions of podman were flaky, but since version 4, which is now a couple of years old, I haven't had any issues whatsoever. I'd recommend anyone using containers on linux to try it out instead of installing docker out of habit.

Cyph0n|1 year ago

+1, Podman is great. I have been running it for a while on NixOS.

But Compose doesn’t mesh well with the overall NixOS configuration system. So I ended up building a custom tool that can convert your existing Compose project into a NixOS config.

righthand|1 year ago

If podman compose would parse env var strings correctly, then it would be on par. Not sure why that hasn’t been fixed but probably because it’s a stepping stone instead of a well thought out replacement.

bombela|1 year ago

The IO through fuse-overlay is performance limiting though. It's almost half the speed as overlay directly for layers with many tiny files.

Note that Linux allows you to mount overlay within a user namespace if you are root within the user namespace.

In other words, if you are root within a container; even though it is not root on the host; Linux accepte ton mount overlay filesystems (most filesystems are not allowed). `man user_namespace`

kuratkull|1 year ago

For posterity, there have been some issues when destroying containers. Errors about "inconsistent state of container" or such. But these have always been about non-running containers, so the answer has been destroy/recreate, so no measurable impact for the business. After spawning and destroying thousands of containers in a high-load live environment(across half a dozen servers), I consider podman pretty stable.

And assuming my own comment is high up, this is the env variable we automatically load:

> DOCKER_HOST=unix:///run/user/1000/podman/podman.sock

forabi|1 year ago

> Rooting for it.

I wanted to say something funny about "rooting" and "rootless", but it's probably too silly. :)

mattgreenrocks|1 year ago

Dumb question: is it rootless for users on something like macOS?

I'd love to get the benefits of Docker without the battery drain and the Docker software, but I'm not sure if Podman would help much with either.

dbacar|1 year ago

> docker-compose with a single env variable what is that env variable?

bityard|1 year ago

> It's also usable via docker-compose

Is that "docker-compose" (with a dash) or "docker compose" (with a space)?

Sparkle-san|1 year ago

> Rooting for it.

No root necessary :)

jacooper|1 year ago

Honestly everytime i wanted to use podman i hit a bug, which is already fixed most of the time but i can't get the new version because they don't have any direct repos to get updates from, this is very helpful for docker.

Also networking in rootless containers still suck.

The end result is just go bakc to docker with less hassle and better stability.

yangff|1 year ago

until you start to use zfs.. (completely doable with fuse overlay, but just painful)

dbacar|1 year ago

To all those interested in podman, this book by Daniel Walsh is a gem. Highly recommended and it is free.

https://developers.redhat.com/e-books/podman-action

5d41402abc4b|1 year ago

The font on that book is so awful. As someone with bad sight i have to strain my eyes a lot to read even a single sentence.

j1mc|1 year ago

I think people are missing the contribution of bootc and composefs. This is a big part of what undergirds Red Hat's new 'image mode' means of deployment. They're using container-related tooling to deploy whole operating systems, and it's a large part of where they're headed.

I write this to say, "This is not them dumping abandonware." To me, it's them putting these technologies under the supervision of a neutral third party to encourage adoption.

jauntywundrkind|1 year ago

Composefs has a totally crucial feature that sold me immediately, which is that if two containers use the same file, the kernel can serve that file from the same page cache. This means you can hypothetically launch a lot of containers, and if they share some layers/base images, the memory usage can still be quite reasonable. Nice. https://github.com/containers/composefs?tab=readme-ov-file#b...

vbezhenar|1 year ago

Is CNCF new Apache foundation? Looks like everyone dumps their stuff there. Does not look promising. Am I missing something? Probably RedHat paid salary to podman developers, but who will pay salary to them now?

nonameiguess|1 year ago

I'm not sure why you think that. Plenty of CNCF projects, if not all of them, are still developed by the same corporate teams that originally developed them, even though ownership has been transferred. Cilium is still being developed by paid Isovalent employees. I'm pretty sure Kubernetes is still maintained mostly by Google employees. Longhorn and k3s are maintained by SUSE employees. This isn't Red Hat's first foray. They bought CoreOS, which is the company that originally developed etcd, one of the oldest CNCF projects that even predates Kubernetes, and most of its maintainers are still employees of either Red Hat or Google.

gbraad|1 year ago

The podman team and my team, working in the virtualization side (Podman Machine), will continue doing so

lysace|1 year ago

In the same way as how the Kubernetes ecosystem is the new Enterprise Java ecosystem? Often even from the same companies as back in the late 90s/00s.

Look: I'm probably ignorant, but from the outside the similarities seem striking.

Please explain why I'm wrong. I'm humble on this one.

anticorporate|1 year ago

I'm sure Red Hat will continue to pay Podman developers, just like they continue to pay developers for the other upstream projects that are hosted at CNCF (like Kubernetes).

I'm we can all think of some projects "abandoned" to foundations through the years, but in general, I'd call getting core infrastructure out of the control of a single company and into a place with more transparent and democratic governance a good thing.

EdwardDiego|1 year ago

Strimzi is CNCF, Strimzi still has a full time team of devs in RH.

NewJazz|1 year ago

Does podman support docker compose files well? Devs love them for local environments.

jeppester|1 year ago

I use podman with docker-compose files for my day-to-day work; spinning up databases and other service dependencies for locally running or containerized webapps.

podman-compose never worked very well for me, so I'm running with the podman.socket systemd service and the standalone version of docker-compose. That is however working flawlessly.

What I really like about podman (and which to be fair docker might have since catched up on) is that rootless containers work so well. Gone are the days where bind-mounting a project folder into a container would mess with your file permissions.

In my experience podman also feels easier and less invasive to install, although I can't say if the latter is really the case.

spockz|1 year ago

I’ve been using it on my Fedora server because I make myself. I think all functionality and syntax is covered. However, the user feedback and TUI of docker-compose is way nicer (interactive at least). Also, podman compose does seem to recreate containers that do not need to be recreated in more cases than I have noticed docker compose do.

lytedev|1 year ago

I've been using podman-compose, yes.

dbacar|1 year ago

Yes it doesm even with rootless. We are using it in prod.

RcouF1uZ4gsC|1 year ago

Reading about Keycloak and how long it is taking to patch critical vulnerabilities, I wonder is CNCF becoming how Apache was - where abandoned open source software goes to die.

caniszczyk|1 year ago

Last I checked, Keycloak has increased in activity since joining CNCF...

https://keycloak.devstats.cncf.io/d/1/activity-repository-gr...

CNCF has probably 20x the funding of the ASF and is a different organization that spends millions of dollars on security audits, events and more, you can read about it in our annual report: https://www.cncf.io/reports/cncf-annual-report-2023/

Also we actively remove/prune projects that aren't active... we will probably archive ~10 this year https://www.cncf.io/project-metrics/

preisschild|1 year ago

I think being a CNCF project is better than not being one. It gives it more visibility and structure and thus is less likely to be abandoned.

But sure, unfortunately if not enough different companies and individiuals are maintaining stuff it gets abandoned.

pphysch|1 year ago

Hopefully the Keycloak thing will spur more competition. I looked at some alternatives and settled on Keycloak because it was "obviously" the mature and hardened solution.

Well, clearly not.

gigatexal|1 year ago

This is cool and all I just want to make sure podman and others are maintained and useful. I’m sure they will be it’s just that I use podman every day and depend on it.

I could go back to docker but why?

greatgib|1 year ago

Usually, when big orgs like that dump their projects to such a foundation (like Apache), it is that they are about to drop investing in support it soon.

philipwhiuk|1 year ago

Hmm maybe worth switching from Docker Desktop to Podman Desktop...

xer0x|1 year ago

What took them so long?

nijave|1 year ago

My take was they sort of dug in said "Docker isn't made right for Linux, we're reinventing it"

On Fedora w/ SELinux that led to quite a bit of compatibility issues for a while with lots of quirky things that didn't behave the same.

I think their implementations have gotten pretty stable and improved in compatibility since then

tecleandor|1 year ago

Waiting for IBM to buy them? (half joking)