Podman vs Docker

Podman vs. Docker – secure containerization

Podman 2.0 is a container development and management tool made available in the eighth version of EuroLinux. The software is compatible with Docker and offers many security benefits, mainly due to the ability to operate from the level of the unprivileged user (root less) and to abandon the daemon process (daemon-less).

Podman 2.0 is a container development and management tool made available in the eighth version of EuroLinux. The software is compatible with Docker and offers many security benefits, mainly due to the ability to operate from the level of the unprivileged user (root less) and to abandon the daemon process (daemon-less).

One of Podman’s assumptions is a Docker-compatible API. Therefore, almost all Command Line Interface (CLI) commands from Docker CLI are also available in Podman. The following sample commands are equivalent:

docker run -itd --name nginx --privileged -v ~/www:/usr/share/nginx/html -p 8090:80 nginx
podman run -itd --name nginx --privileged -v ~/www:/usr/share/nginx/html -p 8090:80 nginx

By habit, many Podman users also use the command:

alias docker=podman

The biggest difference between Docker and Podman is the architecture. Docker is based on a client-server architecture, while the daemon process has been completely abandoned in Podman.

Podman vs. Docker

When working with Docker, you use Docker CLI, which communicates with Docker’s daemon in the background. The main logic of the program is in the daemon, which builds images and operates on containers. This daemon works with root privileges. This also means that an improperly configured container in Docker can potentially access the host file system. The Podman architecture, on the other hand, allows you to work with the user who runs the container, and that user does not need root privileges to run the program. Non-privileged containers have a huge advantage over containers that run with root privileges – if an attacker is able to hack a container and escape from it, the intruder still remains an unprivileged host user. This solution creates an additional protective layer.

Podman supports Dockerfiles by default, but lacks Docker Compose functionality. Here, an independent project placed on GitHub, called podman-compose: https://github.com/containers/podman-compose can be helpful. Docker runs as a single process and this can lead to a so-called “single point of failure”. All “child” processes are the property of this one process – if Docker daemon fails, then all child processes are orphaned.

It is possible to include the --all / -aflag in the rm and podman rmi commands. For many users, this is a helpful feature that can only be obtained in Docker with a combination of several commands.

What other advantages does Podman have?

Podman 2.0:

  • can use popular container registries (such as Docker Hub or Quay.io) because images created by Docker and Podman comply with the Open Container Initiative (OCI) standard
  • uses systemd integration to support running containers in the background, as it does not have an additional daemon process
  • allows you to create and manage Podami, a group of one or more containers that work together. This facilitates the subsequent migration of the workload to Kubernetes and the orchestration of Podman containers
  • can use UID separation using namespaces, which provides an additional layer of isolation when running containers, i.e. security
  • can generate a YAML file for Kubernetes only on the basis of a running container (with the command podman generate kube).

Summary

Podman is faster, more efficient, takes up less disk space, and requires less dependency on Docker. Docker is a monolithic tool that tries to do everything – which is generally not the best approach in IT. In business applications, it is better to use safe and specialized tools. For this reason, among other things, Podman has become the default container engine in EuroLinux 8 and other Enterprise-class Linux systems.

Authors

The blog articles are written by people from the EuroLinux team. We owe 80% of the content to our developers, the rest is prepared by the sales or marketing department. We make every effort to ensure that the content is the best in terms of content and language, but we are not infallible. If you see anything that needs to be corrected or clarified, we'd love to hear from you.