Docker is dead? Podman – an alternative tool?
source link: https://content.fme.de/en/blog/docker-is-dead-podman-an-alternative-tool
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Docker is dead!?! Podman
Source: Fight icons created by smalllikeart - Flaticon
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.
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 story behind Docker.
Beginnings of containers and Docker
Docker is an 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
IThen, 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?
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 und -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.
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
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
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-calledUnikernels. These are briefly mentioned here for the sake of completeness, even though they currently have no significance in the Kubernetes context. An interestingBlog 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.
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.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK