Somehow a lot of these blog posts seem to get the fine technical details of the marketing speak wrong.
> Docker recently changed the license
From my understanding this is related to Docker Desktop not Docker. I'm pretty sure Podman can't replace Docker Desktop.
This is also what the linked website says.
Or did I miss something?
And in the linked Blog post it says
> Docker was dropped from Kubernetes.
which from my understanding is also incorrect, because it's the docker-shim which is deprecated (not dropped) and Docker inc could probably make Docker Engine CRI compliant.
It seems to me that almost no one understands the difference between the various layers of "Docker" (that is to say: Desktop, CLI, daemon, containerd, runc) and which layers tools like Podman aim to replace.
From what I've seen in all these Podman articles, I've come to the same conclusion as you.
This is how Podman fits in:
Podman (and its various components) can replace everything but parts of Docker Desktop, namely the GUI that Docker Desktop, has. For everything else, it has it's own Docker compatible CLI, an optional daemon (by default it's daemonless), there is no containerd component as it communicates directly to any OCI compatible runtime. They've also implemented their own OCI compatible runtime, crun, which is supposed to be faster than runc, and more lightweight.
I suppose for the average Joe/Jane this probably doesn't matter. They want to run a few commands the first time around to set up, and then do "start/stop/remove my container" and that's all they want to do.
Docker Desktop isn’t really about the GUI so much as the management of, and host integration with, a Linux VM for running on non-Linux OSes. Notably, there’s no Docker Desktop for Linux, only macOS and Windows.
Yep. Podman takes cares of those things using the `podman machine` sub-command. From what I understand, currently only macOS might be working, but Windows support will be coming if it's not already there.
the only issue really left is that volume mounts don't work with podman machine as of yet. The issue has been live on github for awhile, but its finally getting traction. Likely because of the recent Docker for Desktop changes.
AFAICT podman machine relies on VirtualBox. This would be an enormous performance and resource regression on MacOS — Docker Desktop uses the much more performant and resource-conscious native hypervisor frameworks instead.
My understanding is that Podman is working on a "GUI" since it is one of the most requested items. Taken from the interview with the founders of Podman over on the Google Kubernetes podcast: https://kubernetespodcast.com/episode/164-podman/
- Docker Compose (because podman-compose has a large amount of open issues https://github.com/containers/podman-compose/issues)
- Docker Swarm (since Docker provides a lightweight orchestrator out of the box), you'd need to use something like K3s or another Kubernetes distro
- anything that uses the Docker socket (/var/run/docker.sock), so you can forget about running anything like Portainer or any of the other tools out there
No longer true. Podman nowadays ships with an optional daemon that serves a Docker-compatible interface, so you can use docker-compose directly if that's what you want.
Of course, there's no Swarm support, as evidenced by that very article:
> Caveats
> One known caveat is that Podman has not and will not implement the Swarm function. Therefore, if your Docker Compose instance uses Swarm, it will not work with Podman.
Feels like people will either be pigeonholed into Kubernetes for all of their deployments, or will have to migrate over to something like Hashicorp Nomad: https://www.nomadproject.io/
Yes, but Docker won't work on Windows without having some machine-compatible integration with Hyper-V. Docker Machine was deprecated in favor of Docker Desktop:
I was never able to get docker to properly work with WSL2 without installing Docker Desktop and enabling the integration. WSL2 just seemed too buggy for my likes and I am a happy Arch Linux user.
Podman can replace docker desktop. It doesn't have the same GUI but it does have the capability to run containers via familiar CLI commands on a variety of OSes, connecting to (and in some cases provisioning through podman machine) a VM when required
I also think that it's more than safe to say that K8s is dropping Docker when they've deprecated it as a container runtime
> I also think that it's more than safe to say that K8s is dropping Docker when they've deprecated it as a container runtime
This is wrong. Docker itself is no longer a container runtime: it has spun out that capability into containerd. Kubernetes can now call Docker’s container runtime (again: containerd) directly instead of going through a redundant docker-shim.
In other words: Kubernetes has dropped Docker’s old container runtime in favor of… Docker’s new container runtime.
Volume Mount integration is the big one for me. UI is neither here nor there, but managing the VM is what Docker Desktop means for most users. Podman Machine is getting there, but not quite there yet.
I think you are reading their marketing speak too charitably by assuming it contains "fine technical details". They purpousefully renamed everything to "Docker" to get people think that the desktop virtual machine offering is the same thing and this caused a lot of confusion.
It depends on what you mean by “replace” Docker Desktop, but Podman can run a VM on macOS and has replaced Docker Desktop for me. There’s no fancy (useless) UI nor Windows support yet though.
When you install Docker desktop and already have wsl2 installed you get a pop up saying “you just want us to use wsl2?” And away you go. At least that’s what happened when I did it 6 months ago. Works great!
If you don't need to run `docker` command under Windows, install docker directly from distro repo is enough. No need to run another background service. Another benefit is it is faster to build docker images when the files are large, because it doesn't need to move files between WSL VMs.
AFAICT podman machine relies on VirtualBox. This would be an enormous performance and resource regression on MacOS — Docker Desktop uses the much more performant and resource-conscious native hypervisor frameworks instead.
You are correct on both counts. Most people are not intimately familiar with the details of the Docker and Kubernetes stacks. Unscrupulous vendors have been taking advantage of this confusion to spread FUD and shine a more flattering light on their own products.
podman user here, because of the ability to run in rootless mode.
Using it on RPi4 with Fedora IoT running linuxserver io containers.
Appreciate the systemd integration as well making the containers services that gracefully go down and come up when the pi gets rebooted without me needing to do anything.
I was enamored with this feature too, but a comment here on HN[1] made me reconsider its use. Apparently rootless requires unprivileged user namespaces, which provides a different security context than most apps are expected to run in, and might be less thoroughly tested than you would think.
I still like the systemd integration and that it doesn't require a daemon too, and I still favor it over Docker.
I am generally conservative about these things, but recently the consensus appears to be that unprivileged user namespaces are stable enough for GA. If you work in a targeted environment (e.g., you are a reporter covering civil liberties), maybe you should wait a bit longer, but for average people the advantages of rootless containers probably exceed the advantages of keeping the unprivileged_userns_clone code out of your attack surface.
I would encourage most security-conscious users to enable it and migrate to recent podman over using Docker, assuming a sufficiently recent kernel. The latest batch of major Linux OS releases have all enabled kernel.unprivileged_userns_clone, so Red Hat, Canonical et al seem to agree.
For those interested, though, you can read the anatomy of a userns clone() vulnerability here:
Thanks for linking the original comment. Every container uses namespaces, this is (TL;DR attempt) about user namespaces, which is a not particularly well audited kernel feature, meaning you may open up potentially insecure kernel code to unprivileged users.
The way I understand it, with containers running under a root user, is that to break out of a container you‘d have to find a vulnerability in standard (rootful) namespaces, which is much less likely (since it’s the same thing everything including Docker uses).
But the vulnerability without usernamespaces is much more severe, because the process then has UID 0 on the host.
Frankly if you are that concerned about security (e.g. you have multitenant workloads or are dealing with sensitive data), you should be using KVM or gvisor.
If you're using user namespaces and allowing a previous root only API to be used by a user, it's possible that some escape in that which provides root access (which wouldn't be as huge a deal if it was only ever able to be run as root) allows root level escalation outside the container.
That intermixes with security concerns about what's possible if running as root directly in different ways, and be more or less problematic than a root container depending on the use case, and also more or less likely based on how well those APIs are exercised for the specific use case.
It's not that these should be avoided, it's just that people should be aware that it's not necessarily a pure security increase at the expense of a bit of extra CPU due to kernel checks. There's a bit to consider. Maybe later everyone will consider this tested enough that's it's mostly a pure win. Maybe it's already at that point but people haven't internalized it. I don't know enough to know what stage we're at, but I thought it was worth mentioning, as it took me by surprise when I learned of it.
"the vulnerability" means one specific vulnerability in docker or somesuch "privileged container" i presume. there are also some sleeping in the kernel code that userns opens up, and even outright intentionally allow, that were previously not on the radar.
ultimately we must consider userns vs privileged-ns a fork in the road. one direction sweeps privilege concerns under the rug, and opens up new attack surface today leaving the door open for more non-obvious problems tomorrow. the other relies on highly competent engineers that know the nuances of the system they are working with, and have strong will to stomp out needless complexity from design to implementation.
It’s great that podman serves a good role for you, and I’m not going to argue that. My points:
1. Docker containers absolutely can be run without root. Yes, it’s not the default policy, but containers can have a user ID. If you are referencing the daemon-less root-less nature of podman, that’s a clear advantage of podman vs Docker.
2. Docker containers also have a restart policy which I use to also have them startup on machine reboot. By graceful, you must mean sending SIGTERM to the containers which Docker does as well.
Perhaps podman does these things better, but I want to point out that Docker does have many features for better or for worse.
When people talk about “rootless” in this context, they’re not talking about “launching containers whose process runs as non-root”. The innovation of podman is that a non-root user can “safely” be given permission to launch containers whose maximum permissions are “the perms that user has”.
Docker doesn’t have this functionality: the daemon runs as root, and anybody who is granted access to launch containers by invoking Docker commands can inherently access root-level privileges. The most mundane way to do this is to launch a container with the host’s namespaces instead of generating new ones.
It's not the default setup and not trivial to do, but Docker has had the ability to run the daemon as a non-root user for a few years. The standard .deb and .rpm packages even include scripts to automate the transition for you on Debian and RedHat Linux variants. See https://docs.docker.com/engine/security/rootless/
The only thing podman gives you that docker itself can't is running without a daemon at all.
2. There are security implications, quoting Arch Wiki:
> Warning: Rootless Podman relies on the unprivileged user namespace usage (CONFIG_USER_NS_UNPRIVILEGED) which has some serious security implications, see Security#Sandboxing applications for details.
I'm happy that there are Docker alternatives, but I have the feeling that podman has been hyped a lot recently and many articles and comments give the impression that it's more secure by default and without any downsides.
Why should I trust the Arch wiki? People like Christian Brauner think the value of not running as UID 0 outweighs the increased attack surface from the user namespace.
Probably worth pointing out that docker has had a "userns-remap" option for quite a while, which causes all containers to run in a separate user namespace where UID 0 inside remaps to something else outside, so theoretically a user with access to the docker daemon isn't able to view the outside filesystem as root[0].
I have gone back and forth with podman. At some point it seemed to sometimes get into a funny state where I would simply delete everything[1] to fix it. On all systems where I run docker, I make sure to have "userns-remap": "default" in /etc/docker/daemon.json. Haven't looked into the rootless mode yet, but I was aware a few years ago that they were working on it.
[0] Without remapping root inside a different namespace, anyone with access to the docker daemon can access the outer root filesystem as root using a command such as `docker run --rm -it -v /:/oops alpine`
[1] Amusingly, the simplest way to do this was by using root to run `rm -rf` on my own ~/.local/share/containers/ directory, since the containers used UIDs other than my own (ones that are part of my subuid range)
I love podman. When you write a file to a volume from a container, the user that spawned the container is the owner. This is exactly what you expect, but with docker, everything is written as root. After many years, this has not been fixed:
Podman is not (YET) a drop-in replacement for Docker CE (on Linux), at least for me (even after 3.0.0 release when it adds seamless Docker Compose support, the way it does it contradicts daemon-less...).
Deploying stacks (on Linux) Docker Compose style are typical use cases for using Docker, `podman-compose` works sometimes, however, over half of such initial attempts fail and require tinkering.
Docker CE (at least for Linux) is still the best option when the use cases are simply clone the repo & deploy/run the stack using `docker-compose up -d`, it simply does the job at the best cost.
podman / buildah / skopeo trio is definitely worth learning, podman can be very useful to migrate containerized workloads from local / standalone dev machines to production k8s clusters, by leveraging `generate kube`.
No, it doesn’t contradict daemon-less (wrt resources used by the daemon). This “daemon” only runs activated by a systemd socket for a few seconds. Whereas Docker CE always runs at least containerd (dockerd is also socket activated).
You could argue that conmon is the daemon of podman and every container has its own daemon. It’s a bit wasteful wrt memory but that how it’s designed.
> It's the natural open-source Docker replacement. Docker recently changed the license and plans.
Come on. While maybe not an outright lie, this is certainly bending the truth and leaving out crucial details–Docker CLI is still open source and free, just not Docker Desktop.
While you can use podman on Linux (and should if it fits your needs!), you're not being forced to use it because Docker became paid or anything like that!
I never liked the GUI or desktop behavior. I just install containerd, point dockerd at it, and download everything manually. This is pretty much my install, sans systemd units:
When I found out Podman supports Kubernetes pod YML files with `podman play kube`, I "ported" my Compose files to those, and that works pretty well (in the newest versions of Podman).
I tried to give Podman a go on Ubuntu 20.04 and it _worked_ but I could never get it going with a docker-compose file.
There is apparently support in the works, but I can't find or get that support on Ubuntu at this stage. Shame, I was hoping it might support IPv6 better than docker currently does.
I can’t speak for Ubuntu, but all of my containers are setup in docker compose for podman things start find there is a couple tweaks like container name I had to make, but over all pretty straightforward. I’d recommend another go if you are looking for an alternative.
As I like rootless containers. I think the implementation feels awkward for local directory permission mounting volumes.
When I first used docker on macos a while back, I was surprised with all the telemetry/phoning home it did. It started doing it at the beginning of the installer, before docker was even installed.
I spoke to Red Hat's Dan Walsh, container team lead, and Brent Baude, the lead architect of Podman, on my podcast last week. It's a good primer to the what and why of Podman, Buildah, and all the other "not Docker" tools Red Hat makes.
For programming languages that offer a good experience with static linking, sure, but even those may depend on external config files, environment variables, specific ports and sockets, all of which can potentially conflict with other programs on the same physical host. Go binaries are almost always just one file and yet are among the most popular to deploy as containers along with making up virtually all of the CNCF ecosystem.
The app.AppImage is staged to the network share and started on the remote host. The AppImage might eat all the RAM and the AppImage will get OOMkilled but sshd is unlikely to be killed. When the AppImage gets OOMkilled, the ssh session will end with an error and the ssh client will report that the session terminated unexpectedly.
I've done it (and later cringed). But it definitely works.
Yes, and the more standard "Containerfile" works as well (same grammar but non-branded naming).
Overall, it's a drop-in replacement with additional features and a more linux friendly underlying architecture. You can even alias podman to docker and shouldn't run into any issues.
This is good. The inability to take build artifact inputs into FreeBSD bhyve/jails, is usually why people say they can't go there (it's certainly whats limiting me) -So having an alternate explicitly handle the input I HAVE moving to the product I WANT is really good. Thanks for clarifying.
> Docker recently changed the license
From my understanding this is related to Docker Desktop not Docker. I'm pretty sure Podman can't replace Docker Desktop. This is also what the linked website says.
Or did I miss something?
And in the linked Blog post it says
> Docker was dropped from Kubernetes.
which from my understanding is also incorrect, because it's the docker-shim which is deprecated (not dropped) and Docker inc could probably make Docker Engine CRI compliant.