[HN Gopher] Transitioning from Docker to Podman
___________________________________________________________________
Transitioning from Docker to Podman
Author : indentit
Score : 88 points
Date : 2020-11-20 21:27 UTC (1 hours ago)
(HTM) web link (developers.redhat.com)
(TXT) w3m dump (developers.redhat.com)
| arianvanp wrote:
| 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 and do the process supervision.
|
| I found this very surprising. I still don't understand why they
| made that choice.
| lopatin wrote:
| 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.
| freedomben wrote:
| 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 work going
| on right now to allow Podman to be driven in a similar way if
| needed, but I recently tried to set it up and hit a bug[1].
| CRI-O brings a daemon, and it is used extensively in Kubernetes
| and OpenShift, but not so much outside of that.
|
| [1] https://github.com/containers/podman/issues/8323
| Cu3PO42 wrote:
| I love the idea of Podman being daemonless and (potentially)
| rootless. Regardless of the presence of security flaws in
| dockerd, the Podman architecture just feels cleaner.
|
| And the CLI compatibility is great. Until it isn't. At work we
| switched to Podman for a small deployment because Docker didn't
| yet work with cgroupsv2 and many hours were spent debugging
| Podman-specific issues. In the end switching to cgroupsv1 would
| have been significantly less work.
|
| Therefore claiming you can `alias docker=podman` is a bit
| disingenuous. You can, but only if you don't do anything Podman
| can't handle and what it can and cannot handle isn't immediately
| obvious.
|
| All that said, I wish the project the best and hope it reaches
| the maturity where this alias actually does work.
| sdan wrote:
| > 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
| xenocratus wrote:
| Would that be covered by the same issue as Google v Oracle?
| igneo676 wrote:
| Maybe, but it wouldn't matter if they're OSS to begin with
| xenocratus wrote:
| That's true, don't know why I didn't think of that to begin
| with, just saw them as "products" from two companies.
| joncp wrote:
| I 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.
| nickysielicki wrote:
| I find it somewhat surprising that we haven't seen more
| adoption of the redhat docker (lowercase d) replacements after
| Docker (uppercase d) started pushing some of their monetization
| efforts.
|
| The conclusion that I have to reach is that there are more
| docker users on Macbooks than I realized.
| [deleted]
| GordonS wrote:
| I was just thinking the same thing, and was going to ask if
| there was anything like Docker Desktop, something to make it
| simple to use on Windows/MacOS!
| mikey_p wrote:
| Before there was Docker Desktop on Mac there was Docker
| Machine.
|
| And of course there's a Podman Machine:
| https://developers.redhat.com/blog/2020/02/12/podman-for-
| mac...
| laaman02 wrote:
| Maybe it doesn't count but podman works great on WSL2 as far as
| I can tell.
| throwaway894345 wrote:
| 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 direction.
| yjftsjthsd-h wrote:
| How are you using Docker that doesn't need a bespoke file
| format? You're building from a Dockerfile and either
| scripting around the docker command or running docker-
| compose.yml
| Spivak wrote:
| 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.
| Grollicus wrote:
| 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?
| joana035 wrote:
| > 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
| direction.
|
| Docker was created to give an extra life for legacy
| applications depending on outdated packages, the concept of
| gluing all dependencies withing a compressed rootfs and
| shipping that, with low effort.
|
| Docker became popular because of that, but seems that did
| more harm than good for the ecosystem in terms of security,
| that why podman might have a great future. The docker
| interface is bad and comparing that with systemd is quite a
| stretch. ;)
|
| Anyhow, aren't systemd units ini files? The journalctl ships
| with man pages though.
|
| Aren't containers just processes with namespaces and cgroups?
| gigatexal wrote:
| Any 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?
| choeger wrote:
| Not really corner cases, but compatibility from rootless podman
| to docker ends where privileges are needed, e.g., in the case
| of networking.
| piaste wrote:
| Not sure if you count it as a corner case, but podman lacks a
| docker-compose equivalent - last I checked, a few months ago,
| there was only a community port project that still needed a lot
| of work.
| pydry wrote:
| No need to run a daemon. Security is better.
| tick_tock_tick wrote:
| This isn't about root inside the container but rather it
| doesn't need root on the host system.
| fisxoj wrote:
| 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.
| freedomben wrote:
| I use that nginx image too, and it's the one thing that keeps
| me using docker for some small single-node setups. For
| basically everything else, Podman is a better experience. Now
| that I've discovered Podman can run K8s Pods (and now
| Deployments) I use it _all_ the time. I don 't know how I
| lived without it!
| [deleted]
| kitotik wrote:
| Daemonless and rootless are killer features.
|
| The lack of filesystem isolation and volume support are the last
| things keeping me from jumping ship.
| lifty wrote:
| Rootless is coming to Docker as well since containerd switched
| to cgroups v2, which was a requirement for rootless
| AkihiroSuda wrote:
| Docker has been supporting rootless mode since 19.03
| AkihiroSuda wrote:
| Podman already supports `podman volume create`, though it
| doesn't support volume plugins.
| ranadeep wrote:
| 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 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.
| choeger wrote:
| 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.
| zomglings wrote:
| Why do you say that docker-in-docker buys him nothing? It's
| not obvious at all and you go into no detail whatsoever to
| back up your opinion.
|
| In my experience, that is not true at all. Docker-in-docker
| allows me to deliver smaller images that can fit into a CI
| flow as language plugins instead of shipping a beastly 5G
| docker image with every possible language runtime I need to
| support for my CI tool.
| core-questions wrote:
| > beastly 5G docker image
|
| my beastly 12GB image that even includes Matlab wants a
| word with you
| joana035 wrote:
| >> beastly 5G docker image > my beastly 12GB image that
| even includes Matlab wants a word with you
|
| Perhaps in the next 10 years we will be rediscovering
| packages. :P
|
| If you are in the business of charging complex prices per
| bits over the network, then docker seems to be quite a
| good investment and making it as popular as possible is a
| good strategy to print money. /s
| joana035 wrote:
| It is because to build the image using docker requires the
| docker client to talk with a dockerd daemon, so one has to
| configure the client to access the dockerd which allow
| untrusted code to run as root in the host.
|
| Docker-in-docker is a workaround to make docker work in CI.
|
| Basically a security nightmare and bad design that podman
| doesn't have.
| yjftsjthsd-h wrote:
| Okay, I want to build a container image using gitlab CI,
| which runs builds in docker. How would you like me to build
| an image without using docker in docker, or buildah in
| docker?
| joncp wrote:
| 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?
| znpy wrote:
| Just spent the last two days messing up with Keycloak on
| kubernetes... I feel you.
| fredthomsen wrote:
| Heavy compose user here, and when I tried the podman equivalent
| of compose was missing some functionality that made me move
| back.
| Jonnax wrote:
| Is 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?
| choeger wrote:
| 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.
| yjftsjthsd-h wrote:
| Do you mean in that adding a user to the docker group is
| effectively handing them root? Because if you don't do that,
| then running docker requires root/sudo, which means that it
| should be exactly as secure as anything else
| x87678r wrote:
| I really struggled with podman, a bunch of containers (I cant
| remember which ones) didn't work, and build tools choked as well.
|
| At work we dont get root access so I thought it would be perfect
| but sysadmins couldn't figure out how to configure either so was
| bust there too.
| [deleted]
| aduffy wrote:
| I've also personally struggled a lot with this at $WORK, but
| some of the new features in RHEL 7.8+ (specifically GA'ing of
| the fuse-overlayfs graph driver) have actually alleviated a ton
| of the issues I've seen previously. If you haven't tried that
| I'd certainly recommend it, YMMV
| siscia wrote:
| I had the opposite experiences, everything worked out of the
| box.
| dnautics wrote:
| I just installed my new $WORK docker-compose using podman and
| podman-compose, and it worked out of the box. To be fair, I
| failed at it one time before at previous job... So... Coin
| flip?
| znpy wrote:
| 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.
| fuzxi wrote:
| So run it as root then? Am I missing something?
___________________________________________________________________
(page generated 2020-11-20 23:00 UTC)