They've also built an incredible ecosystem around podman itself. Red Hat has been absolutely cooking with containers recently.
- Pod is significantly simpler than Docker, notably Podman doesn't need to run a background process, your containers run directly as separate processes.
- Podman avoids some long-standing security design weaknesses in Docker ("rootless"). Docker rootless _is_ a thing but has compatibility limits.
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
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
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.
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.
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.
I like it because I am deploying to GCP, and storing containers in Artifact Registry. Cloud Build has good interop with those other products and terraform, so its pretty convenient to live with.
The pipelines themselves are pretty straight forward. Each step gets an image that it is executed in, and you can do anything you want in that step. There is some state sharing between steps, so if you build something in one step, you can use it in another.
In podman, you have to use the "full path" to work with docker hub. Eg `docker.io/library/nginx`.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
Docker Compose is really great for multi-container deployments on a single machine. And Docker Swarm takes that same Compose specification (although there were historical differences) and brings it over to clusters, all while remaining similarly simple. I'm surprised that ourside of Docker Swarm, Nomad or lightweight Kubernetes distros like K3s there haven't been that many attempts at simple clustering solutions. Even then, Kubernetes (which Podman supports) ends up being more complex.
Can you provide any documentation about that?
If you already have colima lying around, that means you have lima and lima ships with both podman and podman-rootful templates:
limactl create --name=proot template://podman-rootful --vm-type=qemu --cpus=4 --memory 4 --disk 20
# it will emit the instructions at the end, but for context
podman system connection add lima-proot "unix:///$HOME/.lima/proot/sock/podman.sock"
podman system connection default lima-proot
podman version # <-- off to the racesI 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.
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.
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.
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...
And while we’re at it, what’s your favorite non-sudo Docker alternative? And why?
Shameless plug: Alternatively, if you are on NixOS, you can just use compose2nix.
Have they started releasing packages yet?
On my Debian box, I build the podman release target in a chroot, extract the archive in /opt/, and use stow to install/uninstall the package. You'll also want the latest crun, but which I also place in stow and install with stow.
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
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.)
How does one install podman on Debian and how does one get a Debian image to run inside podman?
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
I had so many problems that I went back to Docker, because current Podman didn't seem to be trivially installable on Debian 12.
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.
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?
Podman has much better systemd integration: https://www.redhat.com/en/blog/quadlet-podman
podman run -it debian bash