Docker is trusted by a lot of developers all over the world when it comes to building, sharing, and running apps anywhere — be it Kubernetes or your local machine. However, times have been challenging for Docker in recent past. First, the maintainers of Kubernetes deprecated Docker as its container runtime in favor of runtimes that use the container runtime interface (cri), like cri-o or containerd. Now, Docker Desktop will no longer be free for enterprises.
I always wondered: Is it possible to completely get around Docker Desktop? It’s time to find out by having a look at Podman as a replacement for building, pushing and running containers on local machines.
Note: I still consider Docker Desktop a great product, and the tradeoff between implementing Podman as an alternative or paying your team to use Docker Desktop is up to you. Is it really worth your team’s time to deal with an alternative stack?
Introduction
Podman is a daemon-less container engine hosted as an open-source project on GitHub, that’s designed to also work without root privileges. Further, the tool provides a Docker-compatible command line, that can simply alias the Docker commands — thus, no need to remember new ones. 🥳
Architecture
However, one of the biggest differences between Docker and Podman is their architecture. Docker runs on a client-server architecture, while Podman is daemon-less.
Docker uses a daemon, an ongoing background process, to create images and run containers.
💡 A running instance of an image is a container.
Podman has a daemon-less architecture, which means it can run containers under the user starting the container. That’s important when it comes to the next part, root privileges & security.
Root Privileges & Security
Rootless containers refer to the ability for an unprivileged user to create, run and otherwise manage containers. An unprivileged user has fewer permissions than a root user, e.g. additional software packages cannot be installed. Regarding security, minimal permissions help to mitigate potential container-breakout vulnerabilities.
Containers in Podman do not have root access by default, but it’s still possible to run both — root and rooless containers.
💡 Docker added support for an experimental rootless mode.
Installation & Configuration of Podman
As Podman shall be used as an alternative to Docker Desktop, the tool has to be installed and configured first. Depending on the OS of your host machine, the installation process slightly differs. The macOS client for example is available through:
1brew install podman
On macOS, Podman requires a Linux virtual machine, because containers do not run on any other OS due to the containers’ core functionality being tied to the Linux kernel.
The subsequent command initializes a new Linux virtual machine based on Fedora, and takes care of the configuration, like creating a user and generating ssh keys used for connection.
1podman machine init
Last step is to actually start the virtual Linux machine:
1podman machine start
Alias Docker Commands
As mentioned at the beginning of the blog post, Podman was designed to alias the Docker commands. If you want to transition your workflow to Podman, without changing your scripts from docker build … to podman build …, use the following command:
1alias docker=podman
This way, your docker build command is actually executed by Podman. The output that’s printed to the console is different, but at the end, everything should work the same as with Docker Desktop. ▪
