Logo

Docker is better than Podman

I experimented with Podman and realized that Docker is still better

Published: 22 Oct, 2024


I’ve been looking into Podman lately because of FOMO. I’ve been wondering about this whole rootless and daemonless thing.

After having spent a week playing with it, I realized that Docker is superior.

Installation

First, the installation isn’t as straightforward as Docker. They don’t provide packages for Debian based distributions, so you’ll have to rely on what the distribution provides, which is an outdated version. For example. Ubuntu 24.04 provides version 4.9.3 but the latest one is 5.2.x.

If I want version 5.x, I need to compile from source. I can do it once but there’s no way I’m going to compile this everytime there’s an update.

On Windows, you can either install Podman Desktop or Podman for Windows. This confused me at first because I thought they were the same thing. Integrating with WSL also requires you to use a separate package called podman-remote. I didn’t like that because now I have to alias all podman commands to podman-remote. Then if I don’t want to use the Podman machine running on Windows, I have to use the regular podman command. Annoying indeed when compared to Docker.

Daemonless and restart policies

I’ve been looking for a way to automatically start pods when the system boots. Docker can start containers on boot because it has a daemon but Podman requires setting up systemd. It was supposed to be easy by using the podman generate systemd command but they decided to deprecate it in favor of a tool called Quadlet. However, Quadlet can start pods in Podman version 5 or later but not 4.9, which is what I have installed on Ubuntu 24.04. If I want this non-deprecated feature, I need to use something like Fedora, which I don’t like.

Now I have to rely on a deprecated feature to get work done. It’s fine right now but not future proof.

Security

Podman touts itself as being more secure because it’s rootless but this depends on your threat model.

If I’m running Docker on my production web server, I will only allow root or a specific user to access the Docker daemon. This removes the need for being rootless because in order to compromise my system, the attacker will have to first gain access to the user who’s able to control the Docker daemon, which means that my system is already compromised to begin with.

There are some scenarios where an application is able to escape confinement while inside the container but these kinds of attacks are so rare that I decided to not worry about them. Unless I’m handling top secret documents in a spy agency for the government, this doesn’t concern me at all.

So, being rootless is actually a disadvantage for me because I have to go through more hoops to get containers to listen on privileged ports like 443, for example.

Docker for life

And thus, I decided to stick with Docker. Redhat is good at hyping up their products with blog posts and I ended up getting hooked. Now that my head is clear, I’m going to get work done.


Email me if you have any questions about this post.

Subscribe to the RSS feed to keep updated.