Live data from Hacker News

Transitioning from Docker to Podman

developers.redhat.com

61–70 of 278 posts

Re: Transitioning from Docker to Podman

#61
We've tried this (podman 2.0.5) and have hit some really really annoying bugs:

- Build layer cache doesn't seem to work. If I rebuild locally with podman, it correctly detects cache hits and the build is fast. On our Jenkins server (RHEL 8) with podman 2.0.5 it doesn't. It randomly doesn't cache hit, causing builds to take 20x longer than with docker CE.

- Podman is insanely slow at building images in general. COPY emptyfolder/ /emptyfolder/ takes 2 seconds. We have dozens of things to COPY and it's stupid slow compared to docker CE. Buildah doesn't seem any better.

- Systemd integration has bugs. If you use the default generated systemd unit file, it does not kill processes when exiting and leaves them dangling. Even after removing the strange KillMode=none it says to put in there, it still leaves processes dangling. Podman sometimes loses track of the container. It will list nothing in "podman ps" but the processes will still be running.

Re: Transitioning from Docker to Podman

#63

I find the podman integrates with systemd well claims a bit dubious. Last time I checked both podman and CRI-O double fork and have reimplemented process supervision from scratch (through conmon) whilst they could get all those features for free if they didn't daemonize themselves and let systemd handle running things in the background. I found this very surprising. I still don't understand why they made that choice.…

In an ideal world, systemd-nspawn would be the preferred CRI. That was basically the goal of rkt.

Re: Transitioning from Docker to Podman

#64
post #52

Earlier quoted context omitted.

So run it as root then? Am I missing something?

If GP thinks the selling point of podman is that it doesn't have to run as root, but to actually do anything meaningful they have to run it as root after all, why would they use podman?

A rootless docker would greatly simplify some use cases... For example, no need to do docker in docker.

Edit: apparently now net4slirp is recommended... Maybe I'll give it another try.

Re: Transitioning from Docker to Podman

#65
post #32

At my company, we run our CI/CD (Jenkins) using the Docker-in-Docker paradigm to facilitate easy maintainability of the CI itself and allow us to run containerized builds. When we shifted to RHEL 8, we attempted to move this over to Podman and it went miserably (this was back in November 2019). The main reason being is that podman-in-podman doesn't work and had bugs (at least back in Nov 2019). Maybe it fixed now but…

I've found your issues with podman to be a theme for Red Hat projects in general. Have you ever tried to configure Keycloak or OpenShift, for example?

Openshift years ago at least (last time I looked) - SHUDDER! I couldn't believe it was what big business / enterprise was standardizing on as best in class. It looks like it's now Kube / Docker connected, but back then I think it did it's own thing?

The cost in time / $ / config to maintain and operate at the time was not pretty (all this no doubt has changed a lot).

Re: Transitioning from Docker to Podman

#66
post #47

Last time I tried podman it looked very cool being rootless and daemonless, except that since it's rootless I couldn't create the necessary network interfaces... making it pretty much worthless.

Podman 2.1 supports CNI networks (`podman network create`), so it might be worthful now

Re: Transitioning from Docker to Podman

#67
post #15

I was just about to complain about another thing to learn. Then I saw you can do "$ alias docker=podman". Just want to acknowledge the importance of that work. Making things compatible is both boring and a pain, but it's a door opener for people like me who refuse to learn your new API because I know a decent one already.

Completely agree. One thing I want to point out though for anybody not familiar with the differences between podman and docker, for the most part alias docker=podman will "just work" except for these situations: 1. docker-compose. podman-compose attempts to cover this but I've heard it's not quite there yet 2. Mounting the docker socket into the container. Podman is daemonless which means that won't work. There is wo…

It’s now possible to mount a docker compatible socket inside the container using podman.

Re: Transitioning from Docker to Podman

#68
post #65
post #32

Earlier quoted context omitted.

I've found your issues with podman to be a theme for Red Hat projects in general. Have you ever tried to configure Keycloak or OpenShift, for example?

Openshift years ago at least (last time I looked) - SHUDDER! I couldn't believe it was what big business / enterprise was standardizing on as best in class. It looks like it's now Kube / Docker connected, but back then I think it did it's own thing? The cost in time / $ / config to maintain and operate at the time was not pretty (all this no doubt has changed a lot).

They gave you three pods for free until they moved to Openshift 3. I ran an entire startup five years using them without paying a single penny. A nice Heroku alternative. (Iot control server, so basically no load)

Re: Transitioning from Docker to Podman

#69
post #61

We've tried this (podman 2.0.5) and have hit some really really annoying bugs: - Build layer cache doesn't seem to work. If I rebuild locally with podman, it correctly detects cache hits and the build is fast. On our Jenkins server (RHEL 8) with podman 2.0.5 it doesn't. It randomly doesn't cache hit, causing builds to take 20x longer than with docker CE. - Podman is insanely slow at building images in general. COPY e…

Are you trying to use cache-from? This is explicitly not supported:

> --cache-from

> Images to utilize as potential cache sources. Podman does not currently support caching so this is a NOOP.

Re: Transitioning from Docker to Podman

#70

At my company, we run our CI/CD (Jenkins) using the Docker-in-Docker paradigm to facilitate easy maintainability of the CI itself and allow us to run containerized builds. When we shifted to RHEL 8, we attempted to move this over to Podman and it went miserably (this was back in November 2019). The main reason being is that podman-in-podman doesn't work and had bugs (at least back in Nov 2019). Maybe it fixed now but…

> Docker-in-Docker paradigm

Apologies for the patronising comment, but do you really mean that? Docker in Docker works but is intended for the developers of Docker to debug Docker itself. Usually for running Docker from within a container, you just hook up the Docker client to the TCP port of the Docker daemon running outside the container, which isn't strictly Docker-in-Docker.

I ask this in case you're trying a wildly use case (if you really are running true Docker-in-Docker), or are making an unfair comparison (if you're just using the usual Docker client in container to daemon on host). In the latter case, I must admit I don't know what the idiomatic alternative would be for podman, given that I know nothing about it except that it's daemonless (and even that I only learned by reading your comment).

Post reply on HN