Daemonless and rootless are killer features.
The lack of filesystem isolation and volume support are the last things keeping me from jumping ship.
Transitioning from Docker to Podman
21–30 of 278 posts
Re: Transitioning from Docker to Podman
#22At 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 this was our experience. We ended up doing quite a bit of analysis on podman only to conclude it's simply not there yet relative to docker (ecosystem and ergonomics).
There are quite a few corner cases that docker quite simply supports out of the box beautifully that podman doesn't support or just has bugs.
I like the what the project is trying to solve by being daemonless, but this is not as simple as a drop in replacement for docker that RedHat markets it as (alias docker=podman).
We ended up sticking to docker professionally and personally, I am still using docker over podman. The ecosystem and ergonomics are just far too nice to give up over podman.
Re: Transitioning from Docker to Podman
#23Is the Docker daemon actually a huge security hole?
I see people championing Podman because it's daemonless but is it actually beneficial or is it championed because it's Red Hat and a case of security check boxing?
Re: Transitioning from Docker to Podman
#24> One of Podman’s greatest advantages is its complete CLI compatibility with Docker. In fact, when building Podman, Docker users can adapt without any significant changes. For example, you can use the alias command to create a docker alias for Podman: `alias docker=podman` Wow that's a great adoption hack; just alias another program as another
Would that be covered by the same issue as Google v Oracle?
Maybe, but it wouldn't matter if they're OSS to begin with
Re: Transitioning from Docker to Podman
#25Any docker Podman corner cases that people have run into? I like the idea of rootless containers but I can do that ether easily by adding one line to my dockerfile or adding a user flag when I run a docker container. What other advantages am I getting?
Generally, it's been pretty easy to transition for me, but I used to rely on things like the automatic nginx image that you need to mount the docker socket into so it can route traffic to containers when they come up. Since there's no daemon, there wasn't a way to do that. I think people are working on it, but I haven't tried recently.
Work also uses a special docker RUN command that can use the host's ssh keyring to, eg. Install something from a private github repo. Doesn't seem to exist in podman.
Re: Transitioning from Docker to Podman
#26Daemonless and rootless are killer features. The lack of filesystem isolation and volume support are the last things keeping me from jumping ship.
Rootless is coming to Docker as well since containerd switched to cgroups v2, which was a requirement for rootless
Re: Transitioning from Docker to Podman
#27I like the daemonless architecture a lot, but until there's a quick and painless way to install it on OSX and Windows developer machines, you're going to see very limited uptake.
I actually like the idea of Docker as a better systemd (or rather, the interface is better). No bespoke file format, programmable API, no need to google for the right journalctl switches, and then of course the advantages of containers and images over processes and system packages. I’m not suggesting everything should be a container nor that docker is the ideal implementation, but it certainly points in the right dir…
But systemd has all of those things. Everything in systemd can be orchestrated with dbus. In fact that’s all systemctl really is — a dbus client. And the file format is ini. And shell style environment files if you want.
And systemd actually comes with two image launching systems systemd-nspawn and systemd-portable. And then with systemd-machined you can add software that needs virtualization too.
The interface to journald is more complicated than it should be but it’s also really powerful — docker logs doesn’t hold a candle to the kind of filtering it can do.
Overall systemd is a stupidly powerful and featureful supervisor compared to Docker. Just the dependency management alone should demonstrate that. Then you get mounts, swap, socket activation, more powerful restarting policy and the whole suite of isolation and security features.
Re: Transitioning from Docker to Podman
#28I like the daemonless architecture a lot, but until there's a quick and painless way to install it on OSX and Windows developer machines, you're going to see very limited uptake.
I actually like the idea of Docker as a better systemd (or rather, the interface is better). No bespoke file format, programmable API, no need to google for the right journalctl switches, and then of course the advantages of containers and images over processes and system packages. I’m not suggesting everything should be a container nor that docker is the ideal implementation, but it certainly points in the right dir…
Last time i did look into docker it couldn't even tell if a service is up or still starting and there were all kinds of weird hacks around that like "is something listening on the configured port". Did that improve?
Re: Transitioning from Docker to Podman
#29At 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…
Maybe you are just too far into docker. I noticed that a lot of default workflows (needlessly) depended on docker running with privileges. One big reason for that seem to be Mac users that only know docker from inside a VM. However, if you think about what you're really needing for CI you will easily see that docker-in-docker gains you nothing. You can as well use plain docker (or podman). The same holds for privileges. No CI operation should need privileges, if only for the reason that it should never alter the CI system itself.
I encourage you to not take the standard workflows as a given and really think about what you need and I bet you either end up with a use case that can be covered by rootless podman or something that requires real VMs anyways.
Re: Transitioning from Docker to Podman
#30Is the Docker daemon actually a huge security hole? I see people championing Podman because it's daemonless but is it actually beneficial or is it championed because it's Red Hat and a case of security check boxing?
It certainly is a gaping hole. But the machines that docker runs on in my experience have a 100% sudoers ratio, so the practical impact is limited.