What is Podman? Docker’s successor?

Let’s delve into the confrontation between Docker vs Podman.

Is actually Podman the successor of the renowned Docker? Or is it just a wannabe?

What is Podman?

Podman is a container engine developed by RedHat, and yes, if you thought about Docker when reading container engine, you are on the right track.

Podman wants to be the alternative to the well-known container Docker engine, but you may wonder: 

What does RedHat offer through Podman? 

Why should I switch to Podman? 

Is Podman the replacement for Docker or just another competitor? 

it is still early to answer all these questions, but in this article you will discover what Podman’s wildcards against Docker are.

Podman’s user-friendliness

While researching for this article, I stumbled upon a presentation by RedHat engineer Dan Walsh, which started by saying how to replace Docker by Podman and outlined how to perform this migration through some steps.

The first is to run:

dnf install -y podman

Then execute:

alias docker=podman

And he ended his presentation by saying: “Any questions?”

Obviously it was a joke, but the idea was to show that switching to Podman is very simple, since RedHat engineers have paid special attention to using the same nomenclature when executing Podman commands. 

So if you are a Docker user, you already know most of the commands in Podman. 

So indeed it is as simple as, instead of running docker run, running podman run, and the result will be exactly the same.

Dan also refers to a Twitter thread to represent how easy the process is, where another RedHat engineer used his “migration method” using the two commands described above and, after a couple of months, had completely forgotten about it, since he continued using the same commands that had been using in Docker for years.

#nobigfatdaemons

It is a reference to the Docker service (daemon). 

As you may know, Docker is a wonderful tool, with endless advantages and options. 

It is capable of handling everything related to your containers: network, storage, execution, motorization, etc., and all this is managed by the same Docker service, which can bring some disadvantages, since the more containers you use, the bigger and more complex the docker service becomes.

This is why RedHat has decided to develop its tool without relying on a service, and this is the main difference between Docker and Podman.

Podman does not need a great service (daemon) to work.

They have decentralized all the components necessary for container management and have individualized them into smaller components that will be used only when necessary. This decentralization offers a large number of advantages that we will see later.

You know what else is easy and free?

Controlling your very own systems without the need for expensive software full of patches to work is at your disposal:

Podman: Pods or Containers?

Podman has a very descriptive name, and yes, when we talk about Pods we are referring to those same units that we use when dealing with Kubernetes.

Podman is capable of running containers in exactly the same way Docker does, but it is also capable of running Pods.

For those who are not familiar with Kubernetes, we will soon release an article talking about it in more depth, but for now let’s just make clear that a Pod is the minimum measurement unit in Kubernetes. The main difference is that a Pod may contain more than one container. It specially uses a main container together with one or more “sidecar containers” running in the same Pod as the main container, to “help” with the main task it was designed for.

If it sounds like black magic, for now keep in mind that a Pod is a unit where there may be one or more containers. We will delve into these concepts.

Imagine that each of the seals in the Podman logo is a container, so what you have is a pod.

Image management with Podman

Podman uses a tool based on scopio for OCI-type image inspection and management.

With Podman, you can scan OCI images without downloading them, and even better,you can take elements from one repository and move it to another directly without this image going through your device, since you won’t have to download the image in order to see or use its components.

Although Podman is able to build images very similarly to Docker with the Podman build command, the Redhat team also offers us another tool called buildah.

Buildah is an image management tool that is closely tied to the use of Podman. Among its features, it allows us to manipulate an image or a running container to create new images, build the root directory of a container for its handling or create new images in traditional or OCI format. If you want to know a little more about Buildah, here you have the link to its official repository. 

Podman is rootless (Podman security)

Thanks to Podman’s modular architecture, it is not necessary to run containers as root. This is a great advantage, since you can run your containers with different users who have different privileges and without the risk of someone having access to the container service and running containers as root user, and wreaking havoc on your servers.

What Podman does when running as a non-root user is creating a directory in the user’s home directory and storing there all the information for the images and containers this user has. So, for example, if you do a podman image with your non-root user, it will show only the images that this user has created or downloaded.

Another advantage of Podman is that it is capable of using UID separation using namespaces, which provides an extra isolation layer when running your containers.

In terms of security, Docker service leaking is even more dangerous than obtaining root (sudo) privileges.

When you get admin permissions (sudo) and do something on the system, it is always registered in the system audit log, there is always a trace to follow. But if you access the Docker service and do it from a container with privileges and get rid of this container, it is virtually impossible to know what you have done. It is not saved in any log nor is there any record of your actions. Which presents Podman as a safer tool.

Integration with Systemd

Podman allows us to run containers that have Systemd enabled by default, without any modification.

It supports socket activation, so we can use systemd to configure a socket and have access to a remote API through which to communicate with Podman. A series of Python libraries have been developed in order to implement integrations and communicate with the Podman remote API.

In fact, there is already an application called Pypodman developed in Python, which is capable of running everything Podman runs locally, but remotely, communicating with the remote API, which opens up a world of possibilities.

Conclusions

Docker has advantages against Podman: firstly, the distribution and widespread acceptance it has, or tools such as Docker swarm, docker-compose, etc. Right now, if you want to orchestrate containers in Podman, your alternative is to use Kubernetes or, the one I prefer: RedHat, to use Openshift using cri-or, which is the runtime that Podman uses.

There is no clear conclusion on whether Podman is a replacement for Docker or whether it will succeed in dethroning the container king.

What we do know is that RedHat is taking their chances on the world of containers, from the acquisition of CoreOS for its use on the Openshift platform, to the development of Podman, which is currently the default container engine in RedHat 8 and CentOS 8.

Now, what do you think? Is Podman Docker’s replacement? Are the advantages it offers us enough? Do you think it will be able to take its throne?

If you are interested in the world of containers or technology overall, you will be surely interested in what we have in store just for you: