No? Sorry if that's a bit cynical, but Docker is only dying in the opinion of distro maintainers. By this metric, it's been dying for the past 8 years, but everyone is still talking about Docker, not podman.
A related problem I've seen from other complaints made elsewhere is that podman does things just slightly different enough than Docker that it's not a true drop-in replacement.
We've seen that before; where distro maintainers declared software too dangerous/prematurely dead for a while. All it resulted in was community hosted repositories for the old software. (Read: this is why avconv failed.)
Yeah I don't think Docker is the type of tool the typical engineer cares enough about to go out of their way to learn something new, no matter how much better or simpler it may be. I guess it's like git; even though most devs only have a surface level knowledge, dethroning it would require convincing people to learn a new system, and that's not gonna happen no matter how good it is.
Red Hat at least had the muscle to force podman onto some people, but not everyone.
idk, I actively dropped docker as soon as I reasonably could. podman is an objectively better tool by nearly every metric and it has an almost exact 1:1 CLI tool, so there's not really a learning curve besides a few configuration differences
Sometimes I get the feeling all the folks touting podman as a drop-in replacement for docker are doing it in bad faith.
Every few years I try to replace my containers managed through docker-compose and it's always a sure miss. Before podman gained official support for the docker-compose spec, there was an unofficial podman-compose project that sort of worked save for a few podman incompatibility bugs here and there.
So I was delighted to try out the "official" docker-compose for podman. Quickly learned that there's no such package, the official podman-compose is just the same docker compose package, you just use it with podman the same way you would with docker. Despite this glaring inconsistency I decided to give podman a try (if you are going to install docker compose on your system might as well just use docker). Noped out when I tried to create a VPN with a podman container and it was failing requiring me to enable a kernel module (TAP or TUN can't remember exact error) to create a vpn.
Anyone who says podman is a drop-in replacement for docker never used docker much for anything more than running hello-world. I would only recommend podman over docker for someone who's new to containers and has never heard of docker before.
> Noped out when I tried to create a VPN with a podman container and it was failing requiring me to enable a kernel module (TAP or TUN can't remember exact error) to create a vpn.
Those are pretty standard kernel modules for enabling userspace networking, which if you were using podman in rootless mode you need (along with another userspace networking package, slirp4netns). "Drop in replacement" does not mean there's not configuration to get it set up, it means it has the same APIs as another system.
I've been using containers for almost 10 years and with almost no fanfare switched to podman 100% like a year ago. Just because you expected to have to do nothing at all doesn't mean it doesn't work.
Podman doesn't expose an interface for enabling kernel modules. The error message is intentionally intended to discourage users from doing administration on systems, just like the other similar messages you'll get about trying to use "privileged" ports (<1024).
Am sure you can get over the kernel module tun creation and other limitations by using something like --privileged but at that point, why not just use docker if you are going to run containers "insecurely".
And for the sake of this argument, drop-in replacement means I can take my tools and move them over to the alternative with little to no extra work needed on my part.
>Am sure you can get over the kernel module tun creation and other limitations by using something like --privileged but at that point, why not just use docker if you are going to run containers "insecurely".
Because at least you can tell that it's insecure, rather than insecurity being the default?
Secure defaults and containers is kind of an oxymoron.
Also the "secure" defaults don't matter much if you have to manually jump through hoops in sysctl and modprobe to get things to work. Infact I could even argue that this introduces the risk of having an insecure server by misconfiguration.
The page suggests podman in a small info box (one that people might skip, because it feels like the Wikipedian "this article has issues" box), but it also tells you how to install real Docker. Docker has name brand recognition, and even if it wasn't in Debian's official repos, it would be installed from Docker's own repos. This wiki isn't popular enough for this to matter anyway, people are likely googling for "docker debian" and are finding instructions for real Docker. I don't feel like Docker is dying.
And besides, that issue with root feels overblown in the era of single-user systems and servers as cattle.
https://wiki.debian.org/Docker
Docker is dyeing on linux podman will be the only one that remains.