Podman vs. Docker

The key difference between Docker and Podman lies in architectural design. Docker's design is a client-server-based design, whereas Podman excludes the daemon dependency.

Author
Recent Posts

Pablo Brincat

Pablo has 15+ years of experience in information technology, leadership training, and innovative solution engineering. He currently works as Chief Technology Officer and Lead Developer.

What is Docker?

Docker is a containerization platform in which applications, including libraries and dependencies, are packaged safely inside the container. A Docker container is similar to a virtual machine, and Docker containers share the same Linux kernel as the system.

Once we understand how Docker functions, we can see how to manage some of the issues that arise during migration to Podman. The Docker CLI and the Docker daemon are the essential Docker building blocks.

The Docker CLI sends commands to the Docker daemon, which executes the push/pull image from the registry. The daemon then makes copies of the images in the local container and maintains them.

All the work with registries, containers, images, and the kernel is done with Docker. The Docker CLI asks the daemon to carry out this function on your behalf.

So, what's the problem?

A single point of failure can be attributed to a single process.
This process owns all the child processes (i.e., the running containers).
All the child processes are lost if there is any failure in the docker daemon.
Building containers can lead to security vulnerabilities.
The same full root authority has to be conducted by all Docker user operations.

Docker is a gigantic tool that endeavors to do everything—which, generally, is not the best approach in IT. Safer and more specialized tools are more advantageous.

In Docker, the daemon running in the background has been a cause for concern. Running Docker in the CLI requires that the communication is always with the daemon.

Podman vs. Docker

The main advantages of Podman

Unlike Docker, Podman does not rely on a single point of failure.

As Docker depends on a daemon running in the background, whenever a problem arises with the daemon, container management comes to a halt. This point of failure therefore becomes a potential problem. Podman, on the other hand, directly executes and runs instructions on the system without the need for a daemon to manage the containers. Podman execution has two major benefits over Docker.

Podman can be run as nonroot

The Docker daemon runs as root on a Linux system. This alone isn't necessarily a problem except when one exposes the Docker API or adds a user to the Docker group, which provides these users root privileges on the system. In contrast, Podman can run as root or nonroot.

Running Podman rootless

Podman provides enhanced security. Almost all container functionality under Podman can be successfully run on the root or by a nonprivileged user. This is a huge advantage, as it means that one can run the containers with different users who have different privileges.

With Podman, Docker's client/server model is replaced by Podman's traditional fork/execution model. Podman is efficient in applying UID separation using namespaces, resulting in an additional layer of isolation while running containers.

Podman, Docker, and runC

Podman develops, manages, and runs Open Container Initiative (OCI) containers, container images, and groups of containers arranged together on the same host as a container engine.

runC is a lightweight, portable container runtime. Docker is built on top of the runC runtime container. We use the runC runtime container directly instead of the daemon. Without the daemon system, the image registry, containers, and image storage with the Linux kernel via the runC containers interact directly with Podman.

Overall, Podman takes up less disk space, is faster and more efficient, and requires less dependency on Docker. EuroLinux 8, as well as other enterprise-class Linux systems, are well established, with Podman as default container engines.

Additional advantages of Podman

In addition to the advantages mentioned above, Podman offers a couple of additional benefits:

Podman is able to use popular container registries (such as Docker Hub or Quay.io). This is because the images created by Docker and Podman combine with the OCI standard.
Podman uses systemd integration to support running containers in the background due to the daemonless process.
Users can create and manage Podami (a group of one or more containers that work together), thus facilitating the latter migration of the workload to Kubernetes and the orchestration of Podman containers.
Podman uses UID separation via namespaces and therefore provides an additional layer of isolation when running containers, i.e., security.
Podman can generate a YAML file for Kubernetes only on the basis of a running container (with the command podman generate kube).

Migrating from Docker to Podman

Migrating from Docker to Podman is easy:

The commands you use with Docker are the same for Podman.
Docker images are compatible with Podman.

Note that Podman containers and image storage locations are different from those of Docker.

When Podman was developed, it was ensured that Docker users could adapt. This means that all the flags and commands users are familiar with, such as pull, push, build, run, commit, tag, etc., all exist with Podman. The migration process from Docker to Podman is also super easy, since a Docker-compatible command line front end is provided that can alias the Docker CLI using a command.

Before you migrate, be sure to stop Docker so that you can use the alias and Podman local repository paths, which are /var/lib/containers based on OCI standards, instead of /var/lib/docker.

Although Podman supports Dockerfile and docker-compose.yml, if you choose to migrate, you must change the name of Dockerfile to Containerfile and docker-compose.yml to container-compose.yml.

Systemd features, such as sd notify, socket activation, and managing containers with service files, are enabled with Podman's fork and exec architecture without the need for daemons in the background.

Container management tools that comply with ICI standards work with Podman-created images. Images can be pushed to other container registries, such as Docker Hub.

All the commands and functions that assist in maintaining and modifying OCI container images (including pulling and tagging) are Podman specialties. This allows you to create, run, and maintain containers created from those images in a production environment.

Conclusion

In the era of software development using container technology, Docker is the most common tool that uses Kubernetes for container management with Kubernetes distributions, such as OpenShift, Rancher, and Tanzu. Docker is available for most platforms, from personal computers all the way to mainframe PCs, such as IBM LinuxONE, as well as accepted operating systems, such as Windows, Linux, and MacOS.

As such, developers generally look for alternate tools, and this is where Podman comes in handy. Granted, Docker has many features that Podman might not directly replace. But when it comes to software development of container-based applications in a local computer, Podman can be used to build, run container images, and upload to a public container registry like Docker Hub or quay.io.

In conclusion, the use of Podman for launching containers enables more effective security through audit logging. It is a powerful auditing system that is great for keeping an eye on what processes do on a system.

In my opinion, the niftiest feature is the ability to run Podman and containers as a nonroot user. So you will never need to give a user root privileges on the host while in the client/server model. You need to open a socket to a 'privileged' Daemon that is running as root to launch the containers. This process leaves you vulnerable to the security mechanisms in the Daemon, as opposed to security mechanisms implemented in the host operating systems.