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

Podman v6.0.0

blog.podman.io

Post reply on HN
Print view View original

81–90 of 269 posts

Re: Podman v6.0.0

#81

Post by ATMLOTTOBEER »

sudonem wrote: post #73
SwellJoe wrote: post #4

No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation. The new network stuff is a welcome improvement.

I’d wager it’s mainly just that deployment is mildly more annoying and requires more disparate steps. Especially if you want to go rootless (and you should). For someone that isn’t “Linux first” (like a baby developer learning to containerize their apps), the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts (and remembering to enable linger) is somewhat…

I think it’s probably correct strategy wise to just “do the right thing”

They’re essentially long junior devs asking Claude to set up podman

Re: Podman v6.0.0

#82

Post by curt15 »

SwellJoe wrote: post #4

No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation. The new network stuff is a welcome improvement.

Isn't Docker is basically a front end to containerd, the most common k8s container runtime? One could just as well ask why use a completely separate container stack just for local development when docker shares the same business end as the prod environment.

Re: Podman v6.0.0

#83

Post by cdmckay »

After Docker Desktop randomly started consuming insane amounts of memory again we switched to Podman and it was literally as easy as installing it and pointing it at our docker-compose.yml.

Zero changes needed and now I don’t need to keep a daemon running.

Great software.

Re: Podman v6.0.0

#84

Post by psadauskas »

the-grump wrote: post #41
trollbridge wrote: post #39

Earlier quoted context omitted.

I gave up on Podman for some minor reasons: one was that they decided to deviate from Docker and handle SELinux differently, which required effort to change the SELinux security labels on a stock Centos system. That made it a no go. The other issue is minor differences from Docker, but small enough that a packaged up Docker compose doesn’t work out of the box. It’s not a good use of my time to debug that when I could…

Can you elaborate on SELinux? It affected me too but I just had to add :Z to my mount argument. Curious about whether there's further impact I'm unaware of.

This is my biggest gripe. If you're using docker-compose.yml on a team that mostly uses docker, you can't use use that same docker-compose.yml with rootless podman. Any volume mounts that need to be writable (like the app, or databases) need to have `:X` or `:x` as a suffix, or podman won't set the SELinux label correctly to make it writable. But if you add those, docker blows up because it doesn't understand them.

Re: Podman v6.0.0

#85

Post by nyrikki »

tbocek wrote: post #61
SwellJoe wrote: post #4

No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation. The new network stuff is a welcome improvement.

Just today, I tried to run docker compose on a remote host via podman-docker on Fedora (Asahi). I ran into all sorts of buildx issues, and the easiest fix for me was to remove podman and install docker instead. I tried working through it with Claude, but after a few failed attempts I gave up. I'd like to use podman, but the docker compose + buildx compatibility gaps made it more trouble than it was worth for now. I'm…

If you want podman equivalents, you can either use pods of multi containers are the need, or if multi arch builds are the main buildx need, OCI manifests work.

Fedora and selinux may be a thing to look into if you were trying to share volumes.

I am posting this from a park on my phone, so this may be slightly wrong, but this is the multiarch case that seems to be harder to find for many people.

      podman manifest create my-image:latest
      podman build --platform linux/amd64 --manifest my-image:latest .
      podman build --platform linux/arm64 --manifest my-image:latest .
      podman manifest push my-custom-image:latest docker://docker.io/user/my-image:latest
All depends on your needs, but even with docker I prefer moving forward with OCI when possible, preferring standards to product specific workflows.

Re: Podman v6.0.0

#86

Post by threecheese »

satvikpendem wrote: post #78

How is Podman these days? I use OrbStack on macOS and it seems to be much faster, not sure how everything will shake out now that macOS 27 is adding (more) native and performant Linux containers, similar to WSL with micro-VMs.

Same question, same scenario. I tried it on MacOS, and the first issue I experienced (don’t recall what it was) had me deep into Redhat forums to even understand what was happening. Switching to OrbStack was a no-brainer, but there are obvious tradeoffs from a features perspective.

Re: Podman v6.0.0

#87

Post by chrisweekly »

cdmckay wrote: post #83

After Docker Desktop randomly started consuming insane amounts of memory again we switched to Podman and it was literally as easy as installing it and pointing it at our docker-compose.yml. Zero changes needed and now I don’t need to keep a daemon running. Great software.

I liked Orbstack better than colima which was better than Docker Desktop. Then I found https://smolmachines.com's smolvm microvms.

Re: Podman v6.0.0

#88

Post by 2bitencryption »

PufPufPuf wrote: post #77

One thing I don't like about Podman is that it pretends to be docker-compatible while having some minor differences that will come to bite you. And users of your docker-based project who try to run it on Podman will come to you and complain.

I've found most of the differences to come not from the socket API, or the logical behavior, or CLI differences. But instead from assumptions Docker makes, that it's running rootful, when Podman will not (by default).

As such, most of the fixes for Podman/Docker incompatibilities is just addressing that assumption with a few extra flags on the Podman commands to change how the user namespace maps between the container and the host, etc etc.

Re: Podman v6.0.0

#89

Post by rgovostes »

PufPufPuf wrote: post #77

One thing I don't like about Podman is that it pretends to be docker-compatible while having some minor differences that will come to bite you. And users of your docker-based project who try to run it on Podman will come to you and complain.

I've been using Podman on Mac and Linux for 3 years, and unfortunately, I have found this to be perennially true. I am willing to doggedly pursue the root cause and file bugs, but for many people it will just seem broken.

Most recently: Netavark doesn't match Docker's behavior with accepting broadcast traffic on a published port.

Re: Podman v6.0.0

#90

Post by Chyzwar »

cogman10 wrote: post #47
Chyzwar wrote: post #44

Earlier quoted context omitted.

Last time I evaluated podman, Ubuntu was second class citizen. Rootless was non trivial and required additional setup. Documentation also suck. Docker is something we all already hate, milion edge cases and forever bugs but at least well documented and understood. Podman claim to be drop-in replacement does it mean it carry docker shitness? Examples: ufw punch through, env file handling, volumes, etc

With recent advances in both systemd and podman a lot of this is basically a non-issue. Documentation has also gotten better. For tools that require docker to work, like testcontainers and tilt, I've found some annoyances using podman, but ultimately I've been able to work around them. For everything else, it's pretty much a drop in replacement.

They should better manage expectations. They put rootless as a forefront before it was ready and still no proper support for Ubuntu on v4 of Podman.

[1] https://github.com/podman-container-tools/podman/discussions...

Post reply on HN