Podman vs. Docker – what is the future in the container world?

With official support for the popular Docker container management tool discontinued in Red Hat Enterprise Linux 8 (RHEL 8), many administrators have to prepare for a new option. Podman, also from Red Hat, is the newest replacement, and is designed to overcome some of its predecessor’s security concerns by foregoing a central daemon and root privileges. Otherwise, both tools are similar — although Podman does still have to fight with some bugs.

Docker, one of the most popular and widely used container solutions, no longer receives official support in Red Hat Enterprise Linux 8. However, Red Hat provides the solution to the problem directly: Podman. The CRI-O environment is promoted by Red Hat as an equivalent 1:1 solution, so Docker fans can breathe a sigh of relief. But whether Podman can really replace Docker without any limitations is another matter. To be able to answer this question, it is worth taking a closer look at both container technologies first.

Ever since Docker was released as open source software in 2013, it has been incredibly popular. As a lightweight yet viable and reliable solution for application development, Docker allows users to take a flexible approach. Using the image as a representation of a container, packages can be easily transported and installed as data. A single Docker image can create an unlimited number of containers, e.g. OpenStack clouds. Docker is completely isolated in this process, apart from a few interfaces in the operating system or hardware. The containers themselves only contain the information that is really needed and are thus comparatively lean.

Podman is to replace Docker — at least according to Red Hat Linux. Podman was intended as a pod manager for creating and processing containers and is compatible with the OCI container specification. In contrast to Docker, Podman gets by without root rights and is therefore supposed to be more secure in comparison. Podman is based on Docker and was originally planned as a debugging tool before becoming an alternative to the older management tool. To ease the transition, it is possible to use commands from Docker in Podman. However, that alone does not make Podman an equal successor.

However, this is exactly the crucial question. Since support for Docker is being discontinued, users will have to reorient themselves and find a comparably good alternative. While Red Hat Linux sees Podman as this option, many developers are undecided or even dismissive. In order to adequately evaluate the Docker vs. Podman comparison, it is worth taking a look at the strengths and weaknesses of the challenger.

The biggest advantage that Podman has compared to Docker is the lack of a central daemon and root privileges. This not only allows for a faster startup — from a security perspective, this change is also welcome. The host system is protected and processes with root privileges can no longer access the kernel. Podman’s compatibility with Docker is also a big advantage for Podman. The migration is comparatively easy to perform, and the individual steps are also largely intuitive for administrators who are used to the old management.

In addition, it is possible to use popular container registries such as Docker Hub or Quay.io with Podman. YAML files for Kubernetes can also be created. Podman requires less storage space overall and is extremely fast and efficient. Podman is therefore the default solution for many Linux distributions such as Fedora CoreOS.

As much as Red Hat praises Podman, the container engine is not entirely bug-free. Some teething troubles and bugs mean that many administrators are not yet fully on board with Podman and prefer other alternatives to Docker or hybrid solutions such as Kata Containers.

Errors are more common when dealing with containers. Without a daemon on the network, creating and managing containers via a remote host is difficult. Even though Podman offers initial solutions here, these problems have not been solved. This also applies to the promised compatibility of Podman and Docker. Not all requests are understood by the newer tool yet.

A direct comparison of the two engines is crucial to decide which one wins out in the Podman vs. Docker comparison. So what are the differences between the two management systems?

Unlike Docker, Podman does not use a central daemon to develop, manage, and run OCI containers. Instead, Podman is based on the Kubernetes pods. Multiple containers join together within a common Linux namespace. This creates flexible configuration and combination options. Docker does not offer this possibility without additional configuration via docker-compose.

This is also one of the biggest criticisms of Docker. Its daemon requires mandatory root authorization and thus creates a potential security risk. Thus, containers via Docker basically have the possibility to break out and also act on the host. This can potentially lead to major damage on the kernel if, for example, a misconfigured container gains access to the host. Podman solves this problem by allowing containers to be started without root privileges. Administrators cannot execute commands that require root privileges on the host.

In the Kubernetes vs. Docker duel, there are many differences between the two heavyweights, but when it comes to container orchestration, the tools work well together. This will probably change with Kubernetes 1.24, as Kubernetes is discontinuing support for Docker. However, collaboration with Podman should continue to be possible without any problems. The name of the newer system already indicates that Podman (unlike Docker) supports pods established by Kubernetes.

Unlike Docker, Podman follows a fork-exec model action and records changes in the auditd system. This is different with Docker, where there is no recording.

This difference will certainly become smaller and smaller over time. Currently, however, the documentation for Docker is still far superior to that for Podman. Since 2013, the “oldie” has become the standard and has a huge community that supports administrators with help and advice for every problem. The five-year younger successor cannot yet keep up. In the future, the two tools will probably converge in this respect.

Although the design of Docker and Podman is very different, this is of little consequence in daily work. If you know Docker, you will most likely find your way around Podman as well, especially since many commands are familiar and can be easily adopted.

This is exactly what makes the migration from Docker to Podman comparatively easy. Not only are the commands such as “pull”, “push”, “build”, “run”, “commit”, etc. largely identical, the Docker images are also compatible with Podman. This was a stated goal of the developers. Before making the switch, make sure Docker has been stopped. Then install Podman or rely on the pre-installed software in some Linux versions. You will then need to rename “Dockerfile” and docker-compose.yml to “Containerfile” and container-compose.yml.

Podman vs. Docker is an unequal battle, as the older tool has some edge, but is no longer supported by Red Hat. There are good reasons for this, mainly based on security. Docker had a lot of catching up to do here for a long time, and the shortcomings have been fixed in Podman. The lack of a central daemon and the resulting better protection could sooner or later convince even skeptical administrators. However, even Podman is not error-free, and minor problems still have to be solved. If this happens, Podman wins out against Docker by a narrow margin.

Many convinced Docker enthusiasts may sooner or later still switch or reorient themselves and, for example, end up opting for a Kubernetes alternative that Docker can still be used with. However, due to the great similarity of the two container solutions and Red Hat Linux’s efforts to establish Podman as a successor, this switch will most likely work well!