Understanding the Differences Between Podman and Docker

Containerization is all the rage right now. Docker, introduced back in 2014, has become the most popular tool for managing containers. Later, in 2018, Red Hat unveiled Podman as an alternative to Docker.

Since both Docker and Podman are intended to do the same thing, let us see what advantages one holds over the other.

Understanding "containerization" first

Let's assume that you are the IT person in your organization. You are told to deploy a variety of mission-critical software. What if software A and software B have the same dependency but require different versions of the same dependency? Or worse, what if the dependency of software A conflicts with dependency for software B?

In that case, you deploy them in separate virtual machines. But that removes the scalability factor from it. With two virtual machines running [on the same hardware], the software inherits only 50% of the total system computation power. Increase the number of software necessary from 2 to 10 and you understand how ridiculous this gets.

An inherent negative of a virtual machine is that it also runs a full-blown operating system. In this scenario, this is a net negative. If you have ten virtual machines running RHEL, you have ten copies of the same binaries, inefficiently hogging up your RAM. Even the most minimal installation will still result in more than 4GB of disk space per VM.

So, instead of a virtual machine--where you have a full operating system, your software and its dependencies--that is highly inefficient (in this particular scenario), you can have a container image. These container images only have the software and it's dependencies packaged together. An added bonus is that these container images are usually less than 300MB in size!

The problem lies with the nature of virtual machines. When you create a virtual machine, the hardware gets virtualized. That means that the CPU, RAM, storage and other resources are virtualized. This is bound to have a noticeable overhead.

Meanwhile, with containers, the software (your Operating System) gets virtualized. This has low overhead compared to traditional virtual machines.

So why do I need Docker or Podman?

You might have used Oracle's VirtualBox to manage virtual machines in the past. VirtualBox allows you to create, start, stop, pause, modify and even remove virtual machines. That is what Docker and Podamn do too, but for containerized software.

While Docker and Podman have different philosophies, both help you manage your containers. So let us now take a look at how they differ and which one is the best for your use case.

Docker vs. Podman

As I mentioned earlier, Docker and Podman are container management software and are excellent at it. When Red Hat announced Podman as an alternative to Docker, they said that Podman is compatible with Docker's command line interface. Meaning, moving from Docker to Podman will not require any major changes to your existing code. This also means that you can just substitute the docker command with podman and it just works™.

But they still have a few key fundamental differences, so let's look at them.

1. daemon-based vs. daemon-less

The main difference that sets Docker and Podman apart is the way they run on your system.

Docker's core runs as a daemon (dockerd). Meaning, it is always running in the background, managing the containers. Meanwhile, Podman is like your average program; once you perform an action (start/stop a container) using Podman, it exits.

Docker's daemon-based approach has the following benefits for you:

• Allows you to easily auto-start containers when the system boots up.
• Since Docker is a daemon itself, no external service manager like systemd is needed.

That doesn't mean that Podman is bad. Below are the benefits Podman provides over Docker:

• If the Docker daemon crashes, the containers are in an uncertain state. This is prevented by making Podman daemon-less.
• You can use systemd to manage your containers. That gives you virtually unlimited configurability compared to Docker.
• Hooking Podman with systemd allows you to also update running containers with minimal downtime. You can also recover from any bad updates.

2. Security

The biggest argument for using Podman over Docker is security (well, sort of). Podman is pitched as a more secure alternative to Docker.

In my opinion, if you are somewhat of a security-minded person, two of Podman's primary features will attract you. Previously, I mentioned that the main differentiating factor between Docker and Podman is that Podman does not run as a daemon.

The second main feature of Podman is that it can run containers without root access. What does this mean? It means that you do not need superuser privileges to mange containers.

I have three arguments for why you should use Podman over Docker if you have cybersecurity anxiety, like me.

Argument 1: dockerd runs as root

As you already know by now, Docker's core runs as a "system daemon" i.e. as a daemon executed by the root user.

I have already stated the benefits of having a daemon, but running a daemon as the root user has some security issues too.

Primarily, if the Docker daemon (dockerd) gets compromised, you are left with a system where an attacker can get root access. You certainly don't want that, do you?

The advantage of using Podman is visible here. Podman does not have a daemon running. And certainly does not have any strict requirements for root access. This brings us to the 2nd argument.

Argument 2: Podman supports root-less containers

If you somehow learned about Podman, you might have also heard that it supports running containers without root access.

That is certainly very true and extremely good for security.

Let us assume that the Docker daemon is secure. Now assume that the container image you are using has a security flaw. But this is not known by the developer.

If this image is being run in a container that is owned by the root user, you are SOL.

With Podman, you have the ability to run a container without requiring any root privileges. That means, even if a container image has a security vulnerability, only the user who owns that container is compromised. Other users on that system are still safe, especially the root user.

Docker recently got support for rootless execution of containers, but it has a few missing features. Namely, AppArmor support is absent. AppArmor is Debian's and Ubuntu's default Mandatory Access Control (MAC) system.

Argument 3: Automatically update images

Surely this can't be a feature, right? Well, it is.

Consider the 2nd argument I made with a slight difference. In this case, assume that the security vulnerability is known to the developers. Hence, they made a public announcement and a patched image is already available.

All good? Well, yes and no. Docker does not have an auto-update mechanism built in. "And neither does Podman. So what?"

I agree, not even Podman has an auto-update mechanism built in. Or does it? It depends on how you define "built in". Since Podman does not have a daemon of its own, it cannot do regular checks for updates.

But, Podman being a Red Hat product, integrates extremely well with systemd.

I cover automatically updating Podman containers in a separate article. This is done using systemd. It is linked below.

3. All in one vs segregated

After reading until here, you might have realized that Docker has an "all in one" approach and Podman is... different.

What does this mean for Docker users? For Docker users, you only need the Docker binary installed in your system. The docker command can be used to build images, publish images (to registries like hub.docker.com) and manage containers.

But with Red Hat's offering, there are three separate binaries. To build your images, you use the buildah command. If you want to publish the image to a registry like hub.docker.com, use the skopeo command. And if you want to manage containers, use the podman command.

If you want an all-in-one solution like Docker or a segregated solution from Red Hat depends on your preferences. Both do what they are designed for.

In case you are looking for a way to install Podman on Ubuntu, here is a good resource.

4. Docker Swarm

Docker Swarm is handy when you want to scale up your containers using multiple physical/virtual machines. You can put several computers under a "swarm" and they get a specific purpose. You can have a swarm handling only database requests while a different swarm serves a web server.

While this feature is notably absent in Podman. However, you can achieve the same thing using Kubernetes. I'd argue that Kubernetes is more widely used than Docker Swarm and if scalability in terms of multiple machines is needed, your needs are best served by Kubernetes.

Conclusion

Docker is almost synonymous with containers. Podman was created by Red Hat to extend its offering of containerization tools and overcome some of the shortcomings of Docker. Being compatible with docker commands also makes it easier for moving from Docker to Podman without having to forget your Docker knowledge.

It's not that Docker is not improving itself. Adding the rootless is a sign in that regard.

Overall, it is up to you what you want to use. Personally, I have taken a liking for Podman. You can guess that from all the Podman tutorials I have covered here.