[HN Gopher] Fly To Podman: a script that will help you to migrat...
       ___________________________________________________________________
        
       Fly To Podman: a script that will help you to migrate from Docker
        
       Author : edu4rdshl
       Score  : 131 points
       Date   : 2025-02-21 08:52 UTC (14 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | MrThoughtful wrote:
       | I never tried Podman. I guess the benefit is that it runs on
       | demand and not as a always on demon?
       | 
       | How does one install podman on Debian and how does one get a
       | Debian image to run inside podman?
        
         | natebc wrote:
         | 1) Podman is available in default debian repos.
         | https://packages.debian.org/bookworm/podman
         | 
         | 2) `podman run --entrypoint="" --rm -it debian:stable
         | /bin/bash`
         | 
         | in most instances you can just alias docker to podman and carry
         | on. It uses OCI formatted images just like docker and uses the
         | same registry infrastructure that docker uses.
        
           | aragilar wrote:
           | Installing `podman-docker` will do the aliasing for you.
        
           | MrThoughtful wrote:
           | Where does it pull the Debian image from?
           | 
           | I would think the Docker infrastructure is financed by Docker
           | Inc as a marketing tool for their paid services? Are they ok
           | when other software utilizes it?
        
             | FireInsight wrote:
             | On my system it asks between a few different public
             | registries, and dockerhub/docker.io is one of the choices.
             | 
             | t's all public infrastructure for hosting container images,
             | I don't think Docker-the-company minds other software
             | interfacing with it. After all, they get to call them
             | 'Docker images', 'Dockerfiles', and put their branding
             | everywhere. At this point
        
         | pzmarzly wrote:
         | Runs on demand, doesn't require root, can be nested, usually
         | uses newer and simpler primitives (e.g. a few nftables rules in
         | Podman vs iptables spaghetti in Docker). In my experience it is
         | ~90% compatible with Docker. The author explains the practical
         | differences in the blog post
         | https://www.edu4rdshl.dev/posts/from-docker-to-podman-full-m...
         | 
         | It is usually easier to install - most distros ship relatively
         | recent version of Podman, while Docker is split between
         | docker.io (ancient), docker-ce (free but non in repos) and
         | docker-ee.
         | 
         | Not everything is rosy, some tools expect to be talking to real
         | Docker and don't get fooled by `ln -s docker podman`. But it is
         | almost there.
         | 
         | Regarding Debian, just `sudo apt install podman && podman run
         | -it debian` - see https://wiki.debian.org/Podman
        
           | wink wrote:
           | Careful, the version in Debian 12 is old and apparently just
           | barely predates the "good" versions.
           | 
           | I had so many problems that I went back to Docker, because
           | current Podman didn't seem to be trivially installable on
           | Debian 12.
        
             | exceptione wrote:
             | In general, if one is happy to run very old versions of
             | software Debian can be your driver. If not, you are in for
             | pain in my experience. (That is also why Ubuntu as default
             | Linux is a tragedy, old bugs and missing features mean that
             | it is not really attractive to officially support Linux for
             | vendors.)
        
               | wink wrote:
               | I've not experienced something on this scale for many
               | years, "Debian stable packages are so outdated" is mostly
               | a meme. Debian 12 was 1y old when I did this and very
               | often you can _relatively easily_ find a backport or
               | build one - but I think in this case it was either glibc
               | or kernel, that 's why "just run upstream" didn't work.
        
               | WD-42 wrote:
               | What's the point of using a distribution if you need to
               | find back ports or build your own? Distros are, after
               | all, mostly collections of installable software.
        
               | wink wrote:
               | The point is that it works 95% of the time, or probably
               | more like 98%.
               | 
               | If this is a e.g. webserver and I only need my fastcgi
               | backend built by myself, I can still have reverse proxy,
               | database, and every other package be done by the distro.
               | 
               | No one said you _need_ backports. More like: If it fits
               | 90% and one package doesn 't work, you get it from
               | somewhere else - that doesn't invalidate the concept of a
               | distro for me. YMMV
        
               | exceptione wrote:
               | Honest question: wouldn't that make you more nervous you
               | now arrived at an unknown/unsupported configuration?
               | 
               | Boring stability is the goal, but if Debian does not fit
               | as is, then why not find a total package that is somewhat
               | more cutting edge but does fit together? Especially given
               | the fact that Debian does customization to upstream, so
               | esoteric times esoteric.
        
               | wink wrote:
               | It doesn't make me nervous because Debian has only let me
               | down a couple of times over nearly 20 years and for
               | example Ubuntu und RHEL and SLES have let me down dozens
               | of times each.
               | 
               | Also I don't usually run "supported". I just run a system
               | that fits my needs.
        
               | exceptione wrote:
               | Thanks for following up. Yeah, I should rather have said
               | "tested/vetted".
        
             | righthand wrote:
             | I did not have this same experience, all my VPS
             | successfully run Debian's podman package with zero issue
             | running containers.
        
               | wink wrote:
               | Glad to hear. When I brought it up somewhere I got exact
               | the "oh you're running 4.x - we also had that problem,
               | but 5 works fine".
        
         | 2OEH8eoCRo0 wrote:
         | apt install podman
         | 
         | podman run -it debian bash
        
         | vaylian wrote:
         | > I guess the benefit is that it runs on demand and not as a
         | always on demon?
         | 
         | Podman has much better systemd integration:
         | https://www.redhat.com/en/blog/quadlet-podman
        
         | qudat wrote:
         | And you can use systemd to be their supervisor via quadlet:
         | https://www.redhat.com/en/blog/quadlet-podman
        
       | vednig wrote:
       | Just read the source code.
       | 
       | Script does almost all of the things required for the "existing
       | docker containers", migrating networks, blocks, restart mech,etc,
       | that leaves out just one thing migrating any other third party
       | script utilizing docker to podman based instructions. This would
       | highly improve the experience. Goodluck
        
       | kalaksi wrote:
       | What if I'm using docker-compose?
        
         | darrenf wrote:
         | Use podman-compose?
         | 
         | https://docs.podman.io/en/latest/markdown/podman-compose.1.h...
         | 
         | https://github.com/containers/podman-compose
        
           | boudin wrote:
           | Or just use docker compose with podman. There's a section in
           | arch's doc about that https://wiki.archlinux.org/title/Podman
        
         | tengbretson wrote:
         | There are options, but my experience has not exactly been
         | positive.
        
         | Cyph0n wrote:
         | Enable the Podman socket and have it alias the Docker socket.
         | 
         | Shameless plug: Alternatively, if you are on NixOS, you can
         | just use compose2nix.
         | 
         | https://github.com/aksiksi/compose2nix
        
           | kalaksi wrote:
           | I actually am, but want to keep configs more distro agnostic.
        
             | Cyph0n wrote:
             | Your Docker Compose file remains the source of truth, so
             | there is no "lock-in". That's the beauty of config
             | generation :)
        
         | edu4rdshl wrote:
         | You can continue using `docker-compose` (the provider) with
         | `podman compose`. It's the default provider if installed.
        
       | jjice wrote:
       | Has Podman become more user friendly in recent years? I gave it a
       | go about three or four years ago now when Docker began their
       | commercial push (which I don't have an issue with).
       | 
       | This was for some hobby project, so I didn't spend a ton of time,
       | but it definitely wasn't as set-and-forget as Docker was. I
       | believe I had to set up a separate VM or something? This was on
       | Linux as the host OS too. It's been a while, so apologies for the
       | hazy memory.
       | 
       | Or it's very possible that I botched the entire setup. In my
       | perfect world, it's a quick install and then `podman run`. Maybe
       | it's time to give it another go.
        
         | evilduck wrote:
         | This is mostly solved I think. I run Podman Desktop on macOS
         | and just aliased Docker to Podman in zshrc and it just works
         | for me. I don't do any local k8s or anything crazy, but it
         | works with my compose files. I'm going to guess there's still
         | rough edges if you want GPU passthrough or something with
         | complex networking, but for a server and a database running
         | together it matches Docker itself.
        
         | mixedCase wrote:
         | On NixOS it was as trivial as `podman.enable = true;`. IIRC on
         | Arch it was just a matter of installing the package.
         | 
         | It's all daemonless, rootless and runs directly with your host
         | kernel so it should be as simple as it an application of this
         | kind gets. Probably you followed some instructions somewhere
         | that involved whatever the podman equivalent for docker-machine
         | is?
        
         | sieve wrote:
         | It is not user-friendly, but it works flawlessly once you get
         | used to it.
         | 
         | I stayed away from docker all these years and tried podman from
         | scratch last year after docker failed to work for a project I
         | was experimenting with.
         | 
         | Took an hour to read various articles and get things working.
         | 
         | One thing I liked was it does not need sudo privileges or screw
         | with the networking.
        
         | ijustlovemath wrote:
         | My container using is admittedly pretty simplistic (CRUD app
         | with some REST services), but after initial setup I've found it
         | to be extremely reliable and simple to use. They strive for 1:1
         | docker compat so I think it should be pretty easy to migrate.
        
         | IshKebab wrote:
         | It's _almost_ a perfect drop-in replacement for Docker so I don
         | 't see why it would be any less "set-and-forget".
         | 
         | I only ever found one thing that didn't work with it at all - I
         | think it was Gitlab's test docker images because they set up
         | some VMs with Vagrant or something. Pretty niche anyway.
        
           | adenner wrote:
           | In fact, there is even a package "podman-docker" that will
           | alias podman to docker so most of your commands will usually
           | work without modification. (of course, there are always the
           | edge cases)
        
           | moogly wrote:
           | I could not get LocalStack to work on Podman, to my chagrin.
           | And no, doing the "sudo touch /etc/containers/nodocker" thing
           | didn't solve it.
        
           | bigstrat2003 wrote:
           | The one edge case I know of (and have run into) is that
           | podman push doesn't support the --all-tags flag. They have
           | also said they do not plan to implement it. It's annoying
           | because that flag is useful for CI scripts (we give multiple
           | tags to the same build), but not the end of the world either.
        
         | h14h wrote:
         | The biggest difference in my (admittedly limited) experience,
         | is that you need to start a "podman machine" before you can
         | start running containers. This is architecturally different
         | from Docker's use of a daemon, in ways I'm not qualified to
         | explain in more detail.
         | 
         | It's an extra step, but not a painful one -- the default podman
         | machine configuration seems to work pretty well out of the box
         | for most things.
         | 
         | Honestly, for my use-case (running Subabase stack locally), it
         | was seamless enough to switch that I'm a little surprised a
         | bash script like this is necessary. On my Mac, I think it was
         | simply `brew install podman` followed by `podman machine start`
         | and then I got back to work as if I were still using docker.
         | 
         | By far the most tedious part of the switch was fully
         | uninstalling Docker, and all its various startup programs &
         | background processes.
        
           | stryan wrote:
           | Podman only requires `podman machine` if you're using a non-
           | Linux system; this sets up a Linux VM in the background that
           | all the actual containers run on. Docker does the same thing,
           | though I think it sets it up for you automatically.
        
         | seemaze wrote:
         | I've found it very straight forward to work with. I run the cli
         | on macOS to spin up ephemeral containers all the time for
         | testing and simple tasks. Never had an issue.
         | 
         | In the spirit of the OP, I also run podman rootless on a home
         | server running the usual home lab suspects with great success.
         | I've taken to using the 'kube play' command to deploy the apps
         | from kubernetes yaml and been pleased with the results.
        
         | bjoli wrote:
         | The only snag I hit regularly is me forgetting to set :z or :Z
         | on my podman volumes to make it play well with SELinux.
         | 
         | I used to use docker compose, but migrated to podman quadlets.
         | The only thing I miss is being able to define every container I
         | run in a pod in the .pod file itself. Having it integrate with
         | systemd is great.
        
         | johnbrodie wrote:
         | Hasn't become more friendly from what I've seen. The project
         | seems largely centered around K8s, and isn't really investing
         | in fixing anything on the "compose" side. I did the same thing
         | as you when Docker first started going down the more commercial
         | path, and after dealing with random breakages for a number of
         | years, fully switched back to Docker (for local dev work on
         | osx).
         | 
         | Podman machine is fine, but occasionally you have to fix things
         | _in the vm_ to get your setup working. Those bugs, along with
         | other breakages during many upgrades, plus slower performance
         | compared to Docker, made me switch back. This is just for local
         | dev with a web app or two and some supporting services in their
         | own containers via compose, nothing special. Totally not worth
         | it IMO.
        
         | rsolva wrote:
         | Definitely more user friendly, and I love using Quadlets! For
         | people using Flatpaks (Linux), check out the app 'Pods' as a
         | lightweight alternative to Podman Desktop. It is still a young
         | project, but is already a very useful way of managing your
         | containers and pods.
         | 
         | As a side note, it is so _refreshing_ to observe the native
         | apps popping up for Linux lately, it feels like a turning point
         | away from the Electron-everything trend. Apps are small, starts
         | immediately and is well integrated with the rest of the system,
         | both functionally and visually. A few other examples of native
         | apps; Cartero, Decibels, GitFourchette, Wike - to name a few
         | that I'm using.
        
       | lbhdc wrote:
       | Last year I transitioned all of my personal projects to use
       | podman. The biggest surface area was converting CI to use podman
       | to build my docker files, but also changed out tooling to use it
       | (like having kind use it instead of docker).
       | 
       | For the most part this worked without issue. The only snag I ran
       | into was my CI provider can't use oci formatted images. Podman
       | lets you select the format of image to build, so I was able to
       | work around this using the `--format=docker` flag.
        
         | codelion wrote:
         | That's a pretty cool migration story! I've been meaning to give
         | podman a more serious look. The OCI image format issue is good
         | to know about - hadn't considered that compatibility angle. I'm
         | curious, did you notice any performance differences in your CI
         | builds after switching?
        
           | lbhdc wrote:
           | Its been a while, so all my telemetry has since expired, but
           | there was no meaningful difference in time.
           | 
           | I was prepared to roll it all back, but I never ended up
           | running into problems with it. It's just something that
           | happens in the background that I don't have to think about.
        
         | mariusor wrote:
         | Same here. I migrated maybe 5-6 projects from docker to buildah
         | and podman about 2 years ago and never looked back.
         | 
         | Unlike other posts I've seen around I haven't really
         | encountered issues with CI or local handling of images - though
         | I am using the most bare bones of CI, SourceHut. And I actually
         | feel better about using shell scripts for building the images
         | to a Dockerfile.
        
           | lbhdc wrote:
           | Oh hey! I have used your activity pub library, it's very nice
           | :)
        
         | mikedelfino wrote:
         | Are you pulling base images from Docker Hub, or do you build
         | all images from source from scratch?
        
           | lbhdc wrote:
           | I am pulling from a few registries, but trying to move
           | everything to a private registry.
           | 
           | In podman, you have to use the "full path" to work with
           | docker hub. Eg `docker.io/library/nginx`.
        
       | whalesalad wrote:
       | If you are using docker in this carefully assembled stateful way
       | - you are doing it wrong. You should be using docker via scripts
       | and IaaS tooling that will assert your desired setup from some
       | kind of configuration. Meaning, you should be able to easily blow
       | all of that away and recreate it with a single script. Likewise,
       | a transition to podman should involve adjusting your scripts to
       | re-assert that plan against podman instead of docker.
       | 
       | This is a cool tool for the decrepit hand-configured server with
       | no documentation that has been running since 2017 untouched and
       | needs an update... but I would encourage you to not fall into
       | this trap to begin with.
        
         | pinoy420 wrote:
         | Yeah in theory. In practice that never happens for anything
         | other than a vercel app.
        
       | osigurdson wrote:
       | Podman is interesting as well because it can run Kubernetes yamls
       | (to a small extent) which can be handy.
        
         | vaylian wrote:
         | With the command `podman kube play file.yaml`
        
       | evantbyrne wrote:
       | Does Podman have a swarm counterpart, or does running services
       | still effectively require configuring systemd and then switching
       | to kubernetes for multi-machine?
        
         | Spivak wrote:
         | No to the first, yes to the second. Podman has a daemon mode
         | that works like like the Docker daemon, no systemd necessary.
        
           | keeperofdakeys wrote:
           | > Podman has a daemon mode ...
           | 
           | Can you provide any documentation about that?
        
             | stryan wrote:
             | They're probably referring to the podman.socket, which
             | isn't quite like a daemon-mode but means it can emulate it
             | pretty well. Unless there is some daemon mode I missed that
             | got added, but I'd be rather surprised at that.
        
             | Spivak wrote:
             | Yep!
             | 
             | https://docs.podman.io/en/latest/markdown/podman-system-
             | serv...
             | 
             | In places where you're doing a `dnf install podman` all you
             | typically need to do is start the service and then point
             | either the podman cli or docker cli directly at it. In
             | Fedora for example it's podman.service.
             | 
             | I honestly prefer using the official docker cli when
             | talking to podman.
        
         | hylaride wrote:
         | Last I checked there's no native swarm equivalent in podman.
         | Your best bet is nomad (much simpler than k8s if you want to
         | spin some local setups) or kubernetes.
        
           | kitd wrote:
           | _kubernetes_
           | 
           | Podman can work with local pods, using the same yaml as for
           | K8s. Not quite docker swarm, but useful for local testing IME
           | when k8s is the eventual target.
        
           | evantbyrne wrote:
           | Eh, starting with k8s just because I might want kubernetes in
           | five years is a hard sell, given how easy swarm is to setup.
           | devops that does not fulfill an immediate business need
           | should be delayed because that labor is hella expensive.
        
       | dminik wrote:
       | To mirror some of the other comments here: I've had decent
       | success in using podman for my local dev setup (postgres, redis,
       | ...).
       | 
       | I did run into one issue though. Rootless mode isn't supported
       | (or at least easy to setup) when the user account is a member of
       | an active directory (or whatever Linux equivalent my work laptop
       | is running).
       | 
       | Though root mode works, I can't use podman desktop and I have to
       | sudo every command.
        
       | pinoy420 wrote:
       | Why do people consistently like to make their lives harder in
       | software engineering?
        
         | passivegains wrote:
         | programmers ("developers," if you prefer) have trouble with
         | "second order" thinking. we integrate X technology in Y way,
         | maybe with some Z optimization, and that'll solve the problem.
         | 
         | okay, but, like... will it?
         | 
         | is there new maintenance stuff you've completely ignored? (I've
         | noticed this is more common when maintenance is someone else's
         | job.) is it completely new and none of us know about it so we
         | get blindsided unless everything goes exactly right every time?
         | do we get visibility into what it's doing? can we fix it when
         | (not if, when) it breaks? can everyone work on it or is it
         | impossible for anyone but the person who set it up? they're
         | good at thinking up things that _should_ fix the problem but
         | less good at things that _will._
         | 
         | I'm a fan of cross-functional feature teams because others in
         | the software engineering ecosystem like QA, systems people,
         | ops, etc. tend not to have this problem. programmers are
         | accountable to the other stakeholders up front, bad ideas are
         | handled in real time, and- _this is the most important part_ -
         | everyone learns. (I won't say all systems people are
         | cantankerous bastards... but the mistakes they've harangued me
         | for are usually the mistakes I don't make twice.)
        
       | morcus wrote:
       | Podman looks cool, is there any equivalent of Watchtower
       | (https://containrrr.dev/watchtower/) for Podman?
        
         | okl wrote:
         | GitHub issue for podman support, here:
         | https://github.com/containrrr/watchtower/issues/1060
        
         | xrisk wrote:
         | It's in-built:
         | https://docs.podman.io/en/latest/markdown/podman-auto-update...
        
       | vivzkestrel wrote:
       | just a pro tip "if it aint broken dont fix it" if you have a
       | working docker file(s) do not migrate unless there is a ground
       | breaking need
        
         | exceptione wrote:
         | Security might be such a need, but that depends on how
         | important that is for you. On top, docker auto-fiddles with
         | your firewall.
        
       | toprerules wrote:
       | Just want to say everyone should be using podman. Its
       | architecture is way more sane and integrates with Linux on a far
       | more basic level (a regular process that can be started via
       | systemd, etc. instead of a root daemon. Run it as root to get
       | privileged containers).
       | 
       | They've also built an incredible ecosystem around podman itself.
       | Red Hat has been absolutely cooking with containers recently.
        
         | mati365 wrote:
         | Systemd .container services (Quadlet) are excellent. I used
         | them to set up multiple smaller sites without any issues.
         | Containers work just like regular systemd services. I created a
         | small Ansible template to demonstrate how simple yet powerful
         | this solution is.
         | 
         | GH: https://github.com/Mati365/hetzner-podman-bunjs-deploy
        
         | edwinjones wrote:
         | I agree. I have been using it as a drop in docker replacement
         | alongside podman compose via aliases for years now and I often
         | just forget I am not using docker. The only time it bit me
         | recently is when some scripts were looking for containers with
         | docker specific labels and I had to figure out why they failed
         | only for me.
        
       | JamesSwift wrote:
       | I've not looked into podman but this reminded me that I miss rkt.
       | Anyone with experience in rkt and podman able to give me an
       | overview of how they currently differ? I'm not a huge fan of how
       | docker works, so I'd love an alternative.
        
         | jchw wrote:
         | I went from rkt to podman. Podman is compatible with Docker,
         | including the socket/API, but is similar to rkt in that it
         | launches the container as a child when ran directly (versus
         | Docker, which runs all containers and storage operations under
         | the daemon). Podman also has integration with systemd[1] though
         | it mostly just generates boilerplate for you, since it works a
         | lot closer to how actual daemons work. (P.S.: You might want
         | `--new` if you want a new container each time the unit starts.)
         | 
         | Podman also supports running in "rootless" mode, using
         | kernel.unprivileged_userns_clone and subuid/subgids for the
         | sandboxing and slirp4netns for the networking. This obviously
         | isn't exactly the same as rootful networking, but it works well
         | enough for 99% of the use cases.
         | 
         | If you are running Linux, I think using Podman instead of
         | Docker is generally a no-brainer. I think the way they've
         | approached rootless support is a lot better than Docker and
         | things "just work" more often than not.
         | 
         | [1]: https://docs.podman.io/en/latest/markdown/podman-generate-
         | sy...
        
       | deskamess wrote:
       | What's the podman UX/story on Windows if anyone is using it? Say
       | for Server 2022 (prod) and Win 11 Pro (dev).
       | 
       | Does one prefer using WSL2 or Hyper-V as the machine provider?
       | From what I understand, podman provides the container engine
       | natively so nothing additional is required. Do container runtimes
       | like containerd only come into play when using kubernetes? Not a
       | windows specific question, but is there a reason to pick a podman
       | native container vs one in a k8s context. I understand podman
       | supports k8s as well. Other info: No current containers (docker
       | or k8s) are in play.
       | 
       | Thanks in advance.
        
         | woodrowbarlow wrote:
         | on windows, rancher desktop + podman offers a similar
         | experience to docker desktop.
        
       | Nezteb wrote:
       | Protip: if you want to use Podman (or Podman Desktop) with Docker
       | Compose compatibility, you'll have a better time installing
       | podman-compose [1] and setting up your env like so:
       | alias docker=podman              # If you want to still use
       | Docker Compose       # export PODMAN_COMPOSE_PROVIDER=docker-
       | compose              # On macOS: `brew install podman-compose`
       | export PODMAN_COMPOSE_PROVIDER=podman-compose       export
       | PODMAN_COMPOSE_WARNING_LOGS=false
       | 
       | Most of my initial issues transitioning to Podman were actually
       | just Docker (and Docker Desktop) issues.
       | 
       | Quadlets are great and Podman has a tool called podlet [2] for
       | converting Docker Compose files to Quadlets.
       | 
       | I prefer using a tool like kompose [3] to turn my Docker Compose
       | files into Kubernetes manifests. Then I can use Podman's
       | Kubernetes integration (with some tweaks for port forwarding [4])
       | to replace Docker Compose altogether!
       | 
       | [1] https://github.com/containers/podman-compose
       | 
       | [2] https://github.com/containers/podlet
       | 
       | [3] https://github.com/kubernetes/kompose
       | 
       | [4] https://kompose.io/user-guide/#komposecontrollerportexpose
        
       ___________________________________________________________________
       (page generated 2025-02-21 23:01 UTC)