Ive been using Podman for a while for my non-Kubernetes cloud deployments (i.e. small VM based things).
It's worked very well for me after a few initial hiccups a year or so ago.
Now that Podman-compose[0] is in the works, it'll really be comparable in the UX space soon, and outperforms Docker in several ways when it comes to security.
The key difference with Podman compared to Docker is that is does not run a deamon as root, like Docker does, thus all containers are created with the privilege level of the user who created it.
This can be a learning curve for those used to Docker as privileges (e.g. for filesystems, files) and capabilities (e.g. for devices, low level networking) need to be handled more explicitly as opposed to Docker's approach of "simon (root) says".
Additionally, Podman is very light weight due to the lack of a daemon since there is no service or supporting software which needs to run beyond the capabilities baked into Linux.
Podman [supports][1] `docker-compose` now. Just set `DOCKER_HOST` to the path of your Podman socket after activating the service, and it should just work (unless you use Swarm, which is not supported).
It's worth noting for others that (it appears from a quick read, I haven't actually used this yet), the compromise for gaining the "docker-compose" superpower is that you will have to run a podman service (Daemon). This comes counter to some (not all) of the benefits I mentioned above, but is a necessary compromise if one wants the power of compose style orchestration; that is, that there must be some deamon to manage it.
This is not authoritative, I may be mistaken, but this is my educated guess based on a quick read and my knowledge of Docker et al.
The Podman daemon can run as a user service, so the only advantage that would be lost is not having to run a daemon at all (but I don’t think one can avoid that if Docker API compatibility is needed). Is there something else I’m not considering?
No Daemon at all is what I was alluding to. A smaller memory footprint and lower attack surface are advantages of that, it may not be an issue for many/most but is worth pointing out I hope.
Having just fought it, Docker rootless is a pain to set up and feels like a hack; it's not the default behavior, requires a lot of additional setup to get it working, behaves differently than rootful docker, and lastly most documentation assumes you're using rootful docker because it's been the only way for years.
The fundamental architecture of docker makes rootless awkward but the company needs to compete with podman now which is architected to fix many of Dockers deficiencies while maintaining it's many strengths.
Docker has been a great tool but running as root has always bothered me. I'm glad they're evolving but it feels a little too late and the migration to rootless, as far as I'm concerned, is not simple. Currently I'm investigating migrating my homelab and development efforts to podman.
The idea that Podman is "more secure" than Docker is hyperbole. As documented in Arch Linux [0]...
"Podman relies on the unprivileged user namespace usage (CONFIG_USER_NS_UNPRIVILEGED) which has some serious security implications..."
A lot of hype around Podman on HN this week (two FP conversations regarding, but nothing "new" with Podman). Seems to be an intentional push to get people talking about it for not much of an apparent reason.
I just found out about Docker's rootless mode in an HN thread the other day. The docs make it seem simple, with few meaningful limitations. Really interested to hear some more about the additional setup you needed to do, and what behavioural differences you've encountered?
They recommend using Ubuntu. And they are not joking. Just click on the other distros to see the amount of hoops you have to jump through. You can't even get overlay2, which offers the best filesystem performance. Not to mention the benchmarks I've seen have slirp4netns at about ~3% of the performance of root veth. I would consider both of those incredibly meaningful limitations. You have to use sysctl/setcap to get ping working, to bind to ports <1024, muck with systemd to get user processes starting at boot, etc. etc.
It's a tough sell when you can just install root Docker with a single package command and never have to worry about a bunch of caveats that might just break or change on the next release.
It's not that big a deal doing it from scratch, but most users of Docker were already using it and have it setup to run as root. Undoing that is not trivial, definitely not as simple as just uninstalling and reinstalling rootless. You have to nuke your existing containers, images, and volumes, and depending on the package manager, it's not always obvious if uninstalling Docker will undo all the networking and user configuration changes it makes. Just out of curiosity, I uninstalled it on Arch right now and it didn't get rid of the docker0 virtual bridge device, it didn't remove the iptables rules, /var/lib/docker is still there with everything in it. The docker socket is still there, but I'm guessing that would go away if I rebooted, assuming the systemd unit creates that on login.
Extra packages/steps/incantations that to be performed/installed, introduction of a docker context mechanism that requires understanding, lingering inconsistencies with external filesystem mounting as root owner, incompatibility with most existing docker scripts and compose scripts, confusion on how to get back to root mode, etc.
It just didn't feel like a turn key solution. I have no idea how this would work in CI/CD systems though docker doesn't always need to be as secure there. Docker is a great tool but, like a lot of tech, in the mad rush to market, security was an afterthought and nowhere has it felt more clearly to me than in rootless mode.
I do not agree that the architecture makes it difficult to do . The main issue is you have to start the daemon. Systemd can at least manage this for you as an unprivileged user.
That said, certainly a no-daemon approach takes an extra step out of the mix here.
Although true, podman did have this feature first, and it's still experimental and unsupported in docker. Docker provides scripts to attempt the setup automatically if you're on a Debian or Red Hat based system, but if you're using something else, you're on your own, and it's complicated and error prone to do, mostly because configuring the daemon and socket to work without root is way more complex than just adding in UID/GID mapping and installing slirp4netns, which is all you need to do to get rootless podman working. It's even easier now that overlayfs works without root without needing fuse-overlayfs, but you're kind of aced out of luck on the docker side with them only supporting Red Hat and Debian, since I don't think any of those get the latest kernels like you'd get with Arch or something you just customize yourself, other than maybe Fedora Stream?
Is that a new podman-compose? I've been using a script from somewhere else, but it drives me nuts since ctrl-c doesn't stop the containers, just the script. Gonna give this one a try; thanks!
It's worked very well for me after a few initial hiccups a year or so ago.
Now that Podman-compose[0] is in the works, it'll really be comparable in the UX space soon, and outperforms Docker in several ways when it comes to security.
The key difference with Podman compared to Docker is that is does not run a deamon as root, like Docker does, thus all containers are created with the privilege level of the user who created it.
This can be a learning curve for those used to Docker as privileges (e.g. for filesystems, files) and capabilities (e.g. for devices, low level networking) need to be handled more explicitly as opposed to Docker's approach of "simon (root) says".
Additionally, Podman is very light weight due to the lack of a daemon since there is no service or supporting software which needs to run beyond the capabilities baked into Linux.
[0] https://github.com/containers/podman-compose
EDIT TO ADD: I run Linux both on desktop and server so I have no data for usage in Windows/Mac. Docker Desktop, as I understand it, is a Linux VM.