> https://www.flaticon.com/free-icon/fight_1256685

You're no stranger to container images, Docker, and Kubernetes, and you may have heard it said in many places that Docker is dead? You can't explain exactly where this statement comes from, or maybe you haven't quite figured out the topic yet? Then this blog post will help you out.

⚠️ Updated: June, 22nd 2022: This article was originally published on May 29, 2022 and blew up on hackernews.com with a broad discussion of the role of Podman and Docker in the future. This discussion also contained valid criticism and corrections of some erroneously assumed facts. We are very happy that this discussion took place and that it sparked a nice and lively discussion about containers, Docker, Podman and all the other containerization related topics between all the professionals. We want to correct the wrong facts in a transparent way that is why we decided to not change the original article, but extend it with a paragraph at the end where the wrong assumptions will be corrected. Again, thanks a lot for all your feedback! We appreciate it very much!

In this blog post, I would like to briefly explain how the statement comes about, what background it has and what possible alternatives there are with my own impressions.

In particular, I will discuss the alternative Podman - which does not require a background service (daemon) - including its advantages and disadvantages compared to Docker. First, I will explain the OCI and then how Podman works in general. What Podman is not, however, and a list of its advantages over Docker will follow later.

To make a long story short: Container images - especially according to the OCI standard - are not dead and Docker also still has its application areas and accordingly will not die out quickly. This article is much more about the licensing changes of Docker - especially Docker Desktop - and what consequences they entail.

Why is Docker dead? The history behind Docker.

Beginnings of containers and Docker

Docker is open-source software that primarily serves to isolate
applications with the help of container virtualization. It does this by
using Linux techniques such as cgroups and namespaces to implement
containers, among other things. More detailed information on this can
also be found in Docker's official documentation.

Docker was not, as often thought, the first approach in this direction.
The isolation of applications via process isolation - in principle, containerization is this - goes far back into the past of computers. For example, the first approaches can be traced back to the chroot system call (syscall) of the late 1970s. This advance was the beginning of process isolation: separate file access for each process.

However, in March 2013, Docker Inc, initially known as dotCloud, managed to take containerization to a new level that made it usable to the general public by releasing Docker as free and open source software.
Above all, the simple, understandable usability, high reliability and extreme added value of Docker containers led to the great success and revival of containerization in the world of IT in the following years.

Aquisition Mirantis

Source: https://www.mirantis.com/wp-content/uploads/2017/01/mirantis-logo-2color-rgb-transparent.png

Then, in November 2019, Mirantis acquired Docker Inc. along with the Docker suite. Shortly thereafter, Mirantis announced an adjustment to the existing licensing model. Thus, the standard use of Docker including Daemon, CLI and Docker Desktop was previously free of charge. Instead of free use of Docker Desktop until now, this software suite is now available for rent after the transition phase until the end of January 2022, starting at $5 per user/month, provided it is for professional use. Since then, only individuals, open-source communities and small businesses with up to 250 employees or $10 million in annual revenue are exempt.

In addition to this, a rate limit was created in the central Docker registry - the DockerHub- so that anonymous users can only download 100 images and authenticated free users can only download 200 images in a six-hour period.

These operations resulted in the departure of several major vendors and platforms, as they disagreed with the sudden change in licensing terms. With the use of Docker in popular platforms such as Kubernetes, this showed the danger of dependency to Docker Inc. If this company can continue to adjust their licensing model at will, this can result in major consequences for all companies and platforms that rely on Docker.

Exemplary of this followed the announcement by the Kubernetes project that Docker or dockershim will be discontinued as of version 1.24.
RedHat also decided to do so with RHEL 8.Due to these decisions and also RedHat and Kubernetes moving away from Docker, there is an increasing portion of developers moving away from Docker and looking for alternatives. An interesting report on the declining use of Docker can be found here.

Docker Desktop

To understand the scope of it all, here's an explanation of the Docker Desktop application.

Docker Desktop is a software suite for Mac, Windows and now
Linux that can be used to create containerized applications using Docker's own tools. Here, Docker Desktop includes the Docker Engine, docker-cli, docker-compose and a credential helper, among others.

By adapting the licensing model, Docker Desktop may now only be used in its entirety by the exceptions described above, provided that licensing costs are to be avoided.

What is Podman?

Source: https://developers.redhat.com/sites/default/files/podman-logo.png

In the scene, for many, Podman is following in the footsteps of Docker as free software. But what exactly Podman is and that it is not just a simple replacement is explained below.

Podman is an open source and free container management tool for developing, managing and running OCI containers.

OCI-Images and -Runtime

OCI stands for the Open Container Initiative and was initiated by Docker Inc. in 2015. They describe two specifications: The Runtime Specification and the Image Specification.

Any software can implement the specifications and thus create
OCI-compatible container images and container runtimes that are
compatible with each other. In addition, there are the so-called
Container Runtime Interfaces (CRI), which are based on the OCI runtimes and abstract them.

Example implementations of the container runtime interfaces in this context are dockershim (OCI wrapper for the original Docker Engine implementation, see this article), containerd (new implementation of Docker's container runtime interface (CRI)) and cri-o (implementation of the Kubernetes container runtime interface).

Implementations of the OCI images can be found in Docker,
Buildah, kaniko, and Podman, for example. The OCI-compatible
container images can then be executed on a CRI-compatible runtime (containerd, cri-o), which in turn calls an OCI runtime such as runc or runsc. Runc or runsc then start the actual container on the client.

This may seem a bit confusing at first glance, but can be clarified using the article from tutorialworks and the following figure.

The projects involved in running a container with Docker -- Source: Tutorial Works

What is Podman not?

Because Podman - unlike Docker - is not a container runtime, but only an implementation of the OCI image specification, Podman cannot launch images itself. It requires the aforementioned CRI container runtime, which in turn uses the hardware-related OCI runtime such as runc or runsc to start the actual containers.

Podman itself can only take over administration tasks of the containers including build. To execute the images Podman then uses e.g. the mentioned containerd, which in turn runs e.g. runc to actually start the container.

Benefits of Podman

The following is a brief explanation of the advantages of Podman over Docker.

Proximity to Docker

Despite the sometimes significant differences in the implementation of Podman to Docker, the most common commands of Docker can be used one-to-one. For example, common commands like login, build, pull, push, tag, etc. work exactly as expected by the user. Also, Dockerfiles are still used to build the container images. This makes it much easier for a former Docker user to get started.

Additionally, this compatibility of commands helps a necessary migration from Docker to Podman. For example, by setting an alias from podman to docker, most scripts can continue to be used.

Resource requirements and embedding in OS

Podman was built as a lean and efficient solution. As a result, it has a lower overall memory footprint, is considered significantly faster and comparatively efficient. Also for these reasons, Podman has become a standard for some Linux distributions, such as Fedora's CoreOS.

Additionally, Podman is now included in the default repositories of Ubuntu 22.04 LTS, see also this blog post.

Pods

As mentioned earlier, Kubernetes discontinues support for Docker with version 1.24. This means that dockershim must be replaced by another container runtime such as containerd or cri-o.

With Podman, however, collaboration should continue to be possible
without any problems. Podman even supports so-called pods, as can also be derived from the name. These were originally established by Kubernetes and can combine several containers, similar to a
Docker-compose.

Schematic concept of a pod

This makes it a good idea to use Podman to build and test pods locally before rolling them out to Kubernetes. Alternatively, a local Minikube installation would be a good way to test your Kubernetes manifests.
Podman, however, is leaner and correspondingly more performant in small setups.

More about Pods in Podman can also be found here.

Rootless Mode

Podman does not require root permissions to execute its commands unlike Docker which depends on the background process (daemon). Docker requires root privileges or requires the user to be in the Docker group. Should he not be and should sudo not be used, an appropriate error message will be thrown and it cannot be used accordingly.

Why that may be a problem at all, one now asks the question? As already explained, the Docker daemon requires root privileges on the server and thus creates a potential security risk. If an attacker were to break into the container, there is a risk that he could break out onto the underlying server and then infiltrate other services in the network.

Auditing

Unlike Docker, Podman follows the fork-exec model. This means that changes are recorded in the auditd system. This can be an advantage over Docker from a compliance perspective. An exploitation of the audit model in Docker versus the model in Podman can be understood thanks to the following blog post.

Limitations of Podman

There are two main limitations that Podman brings with it. These will be briefly explained.

Linux based

Podman currently only runs stably on Linux-based systems. Under Windows or MacOS it becomes a bit more demanding, although it is possible with detours.

On Windows, Podman can be used well via WSL, on MacOS it can be installed directly with homebrew. However, these solutions are not yet fully developed and are still considered "in development".
More about this can be found in the official Podman blog post.

Personally, I've been using Podman for some time now with a WSL 2 and the Ubuntu distribution and I'm basically very satisfied. Here and there are still minor teething problems, but these are usually quickly fixable via google search.

Docker-Compose

Podman itself does not support Docker Compose to launch multiple
containers locally. There are two alternatives for this. First, there is already a project called Podman-Compose that is supposed to fulfill the core functionalities of Docker-Compose, and second, Podman supports the pods described above. These can also be used to launch and manage multiple containers at once - even via a more Kubernetes-friendly path.

Another useful alternative to Docker-Compose is, for example, the use of minikube or also k3d. These tools can be used to easily and quickly roll out local Kubernetes clusters. These can then be used for development purposes to deploy and test local Kubernetes objects such as deployments, services or pods.

MacOS: Alternative Lima

Source: https://github.com/lima-vm/lima

Besides Podman, there is another alternative worth mentioning:
Lima.

Lima - short for Linux virtual machines - is mainly used as an alternative for MacOS in this context and comes with QEMU (a hypervisor), containerd and nerdctl.

Thus, Lima uses QEMU in the background for virtualization, containerd as container runtime and nerdctl as Docker-compatible CLI for containerd.
Lima is similar to the Windows Subsystem for Linux (WSL) in version 2.

Thus, it is definitely worth a look for our Mac users.

Outlook Unikernel

Another possibility to switch from Docker containers are the so-called Unikernels. These are briefly mentioned here for the sake of completeness, even though they currently have no significance in the Kubernetes context. An interesting blog post on the topic can be found on Hackernoon. It is an interesting construct that may one day find its way into the world of Kubernetes if containers can be replaced by unikernels. Currently, the use of unikernels would not be feasible in my opinion.

Source: https://github.com/cetic/unikernels

Summary

Last but not least, I would like to give a summary of the usage of
Docker and Podman in fme AG to support our point of view.

Many of us have used the Docker suite for years - some continue to use it in ongoing projects, some have already switched to other
alternatives.

There is - as always - no black and white, but many shades of gray in between. Accordingly, there are still plenty of use cases for Docker Desktop, and some customers are also willing to pay the associated licensing costs.

However, there are also many opposing voices to this - both in the community and among our customers. The sudden change of a licensing model is a nuisance there and contributes to the fact that people refrain from this software.

We try to use Podman, Lima or similar free software in newer projects, because we want to stay independent from vendors and licensing constraints. In my opinion, open source and free software is an important cornerstone of successful and promising IT projects. Even Microsoft has understood and lived this in recent years by investing heavily in cross-platform compatibility with products like .NET Core and WSL.

For this reason, I am pro-Podman and the win - in my opinion - goes to Podman and the idea of free software.

Corrections

As explained above, we want to correct the wrong facts in this article. Therefore, this paragraph contains a few corrections and statements.

Mirantis acquired Docker Inc.

This was a wrong assumption. Mirantis did not acquire Docker Inc. but Docker Enterprise which was a part of the Docker Inc. For more information have a look at this article. Another useful article can be found [German only] here.

Podman uses containerd

This was a wrong assumption. Podman directly uses runC or crun instead of containerd using a technology named conmon. Some more useful information can be found in this article.

Docker-Compose not working with Podman

Docker-Compose is working with Podman since version 3.0. Basically, you point to the Podman socket instead of Docker socket and it works just fine. This leads to the phenomenon that you can use docker-based scripts and tools with Podman as they would use docker in general. They will not see any difference and they will think that they use Docker even though they are using Podman.

Rate limits

We said that rate limits in the Dockerhub are a reason why people and companies are changing from Docker to alternatives like Podman. There was a commentary that said that the Container Registry has nothing to do with the container runtime itself. That's 100% true and valid. Even for Podman the Dockerhub - next to quay.io - is the default registry to pull images.

Nevertheless, the Dockerhub is part of the Docker ecosystem and therefore a rate limit of the official docker registry brought our customers to the point of changing the registry to other registry providers or implement their own container registry. Therefore they get rid of this service which is part of the plain Docker ecosystem, so its use in enterprise is decreasing.

RedHat replaced Docker with Podman in RHEL 8

There was a commentary that it makes only sense that RedHat supports Podman since it comes from their own product forge. Thats definetly right!

Still, there are a lot of businesses using and paying RedHat, which automatically leads to a decreased use of Docker vs. Podman. Less uses of Docker means more uses of Podman.

Last but not least, RedHat would not invent Podman when there were not the need of an independent tool to Docker. Podman helps in a few manners where Docker lacks functions like support of Pods, rootless mode etc. Useful information about why RedHat invests in Podman can be found here.