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

With official support for the popular Docker container man­age­ment tool dis­con­tin­ued in Red Hat En­ter­prise Linux 8 (RHEL 8), many ad­min­is­trat­ors have to prepare for a new option. Podman, also from Red Hat, is the newest re­place­ment, and is designed to overcome some of its pre­de­cessor’s security concerns by foregoing a central daemon and root priv­ileges. 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 En­ter­prise Linux 8. However, Red Hat provides the solution to the problem directly: Podman. The CRI-O en­vir­on­ment is promoted by Red Hat as an equi­val­ent 1:1 solution, so Docker fans can breathe a sigh of relief. But whether Podman can really replace Docker without any lim­it­a­tions is another matter. To be able to answer this question, it is worth taking a closer look at both container tech­no­lo­gies first.

Ever since Docker was released as open source software in 2013, it has been in­cred­ibly popular. As a light­weight yet viable and reliable solution for ap­plic­a­tion de­vel­op­ment, Docker allows users to take a flexible approach. Using the image as a rep­res­ent­a­tion of a container, packages can be easily trans­por­ted and installed as data. A single Docker image can create an unlimited number of con­tain­ers, e.g. OpenStack clouds. Docker is com­pletely isolated in this process, apart from a few in­ter­faces in the operating system or hardware. The con­tain­ers them­selves only contain the in­form­a­tion that is really needed and are thus com­par­at­ively lean.

Podman is to replace Docker — at least according to Red Hat Linux. Podman was intended as a pod manager for creating and pro­cessing con­tain­ers and is com­pat­ible with the OCI container spe­cific­a­tion. In contrast to Docker, Podman gets by without root rights and is therefore supposed to be more secure in com­par­is­on. Podman is based on Docker and was ori­gin­ally planned as a debugging tool before becoming an al­tern­at­ive to the older man­age­ment tool. To ease the trans­ition, 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 dis­con­tin­ued, users will have to reorient them­selves and find a com­par­ably good al­tern­at­ive. While Red Hat Linux sees Podman as this option, many de­velopers are undecided or even dis­missive. In order to ad­equately evaluate the Docker vs. Podman com­par­is­on, it is worth taking a look at the strengths and weak­nesses of the chal­lenger.

The biggest advantage that Podman has compared to Docker is the lack of a central daemon and root priv­ileges. This not only allows for a faster startup — from a security per­spect­ive, this change is also welcome. The host system is protected and processes with root priv­ileges can no longer access the kernel. Podman’s com­pat­ib­il­ity with Docker is also a big advantage for Podman. The migration is com­par­at­ively easy to perform, and the in­di­vidu­al steps are also largely intuitive for ad­min­is­trat­ors who are used to the old man­age­ment.

In addition, it is possible to use popular container re­gis­tries such as Docker Hub or Quay.io with Podman. YAML files for Kuber­netes 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 dis­tri­bu­tions 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 ad­min­is­trat­ors are not yet fully on board with Podman and prefer other al­tern­at­ives to Docker or hybrid solutions such as Kata Con­tain­ers.

Errors are more common when dealing with con­tain­ers. Without a daemon on the network, creating and managing con­tain­ers 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 com­pat­ib­il­ity of Podman and Docker. Not all requests are un­der­stood by the newer tool yet.

A direct com­par­is­on of the two engines is crucial to decide which one wins out in the Podman vs. Docker com­par­is­on. So what are the dif­fer­ences between the two man­age­ment systems?

Unlike Docker, Podman does not use a central daemon to develop, manage, and run OCI con­tain­ers. Instead, Podman is based on the Kuber­netes pods. Multiple con­tain­ers join together within a common Linux namespace. This creates flexible con­fig­ur­a­tion and com­bin­a­tion options. Docker does not offer this pos­sib­il­ity without ad­di­tion­al con­fig­ur­a­tion via docker-compose.

This is also one of the biggest cri­ti­cisms of Docker. Its daemon requires mandatory root au­thor­isa­tion and thus creates a potential security risk. Thus, con­tain­ers via Docker basically have the pos­sib­il­ity to break out and also act on the host. This can po­ten­tially lead to major damage on the kernel if, for example, a mis­con­figured container gains access to the host. Podman solves this problem by allowing con­tain­ers to be started without root priv­ileges. Ad­min­is­trat­ors cannot execute commands that require root priv­ileges on the host.

In the Kuber­netes vs. Docker duel, there are many dif­fer­ences between the two heavy­weights, but when it comes to container or­ches­tra­tion, the tools work well together. This will probably change with Kuber­netes 1.24, as Kuber­netes is dis­con­tinu­ing support for Docker. However, col­lab­or­a­tion with Podman should continue to be possible without any problems. The name of the newer system already indicates that Podman (unlike Docker) supports pods es­tab­lished by Kuber­netes.

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 dif­fer­ence will certainly become smaller and smaller over time. Currently, however, the doc­u­ment­a­tion 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 ad­min­is­trat­ors 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 con­sequence in daily work. If you know Docker, you will most likely find your way around Podman as well, es­pe­cially since many commands are familiar and can be easily adopted.

This is exactly what makes the migration from Docker to Podman com­par­at­ively easy. Not only are the commands such as `pull´, `push´, `build´, `run´, `commit´, etc. largely identical, the Docker images are also com­pat­ible with Podman. This was a stated goal of the de­velopers. 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 `Dock­er­file´ and docker-compose.yml to `Con­tain­er­file´ 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 short­com­ings have been fixed in Podman. The lack of a central daemon and the resulting better pro­tec­tion could sooner or later convince even sceptical ad­min­is­trat­ors. 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 en­thu­si­asts may sooner or later still switch or re­ori­ent­ate them­selves and, for example, end up opting for a Kuber­netes al­tern­at­ive that Docker can still be used with. However, due to the great sim­il­ar­ity of the two container solutions and Red Hat Linux’s efforts to establish Podman as a successor, this switch will most likely work well!