Podman is a container engine— a tool for developing, managing, and running containers and container images. Containers are standardized, self-contained software packages that contain everything needed to run anywhere without requiring customization, including application code and supporting libraries. Container-based applications have revolutionized software development over the past decade, making it easier to deploy and maintain distributed and cloud-based systems.
Podman is a Red Hat project that is open source and free download. It’s a relative newcomer to the containerization scene, with version 1.0 being released in 2019. Podman has since made great strides, and his rise has been compounded by the gradual decline of Docker, the project that in many ways created the world of containers as we know it today.
Podman and Kubernetes
If you’re even a little familiar with container-based development, you know the name Kubernetes. As containerized applications became more complex, developers needed tools that could coordinate containers interacting with each other when running on different virtual machines, or even on different physical machines. Such a tool is called a container orchestration platform, and Kubernetes is by far the most prominent example. Kubernetes can work with any container that meets the Open Containers Initiative (OCI) image specification, what Podman’s containers do.
One of the important features of Kubernetes is the concept of pod, an ephemeral collection of one or more containers that is the smallest unit of computation that Kubernetes can manage. Podman is also centered around the idea of a pod, as the name suggests. A Podman pod also includes one or more containers, which are put together in a single namespace, network, and security context. This similarity makes Podman and Kubernetes a natural fit, and from the start, one of Red Hat’s goals was to require Podman users to orchestrate containers with Kubernetes.
Podman vs. Docker
The other big name in the container world that you’ve almost certainly heard is Docker. Docker wasn’t the first container engine, but in many ways it has come to define containerization. A big part of how Docker works is the de facto standard for container-based development – enough that many people use “Docker” as a shorthand for containers.
Although Docker and Podman occupy a similar space in the container ecosystem, they are not identical and they have different philosophies and approaches to how they work. For example, Docker is an all-in-one platform with tools for specific tasks, while Podman collaborates with other projects for certain purposes. For example, it relies on Buildah to create container images.
There are also architectural differences: Docker doesn’t have a native concept of pods, for example. Another important difference is that Docker relies on a running background daemon program to build images and run containers, while Podman launches containers and pods as separate child processes. This aspect of Docker’s design has important security implications, which we’ll discuss shortly.
Docker commands on Podman
By design and necessity, Podman and Docker are broadly compatible. Part of this compatibility can be attributed to adherence to open standards. Since both engines work with OCI-compliant containers, you can create a container with Docker and edit it in Podman, or vice versa, then deploy either container to Kubernetes.
When Podman rolled out in 2019, Docker was so dominant that its command-line interface was now part of many developers’ programming routines and muscle memory. In order to make a potential switch to Podman more transparent, the creators of Podman made sure that its commands and syntax mirrored those of Docker as much as possible. They went so far as to make it possible to define an alias that redirect Docker commands to Podman.
Better security with rootless containers
With Podman and Docker working so similarly in so many ways, why would you choose one over the other? Well, one important reason is security. Remember that Docker relies on a daemon to do a lot of its ongoing work? This daemon runs as root, making it a potential entry point for attackers. It’s not an insurmountable barrier to secure computing, but it does mean you need to think about navigate Docker security issues.
In some situations, you’ll want to run a container with root privileges on its host machine, and Podman lets you do that. But if you’d rather keep your containers safely scoped to userspace, you can also do that by running something called a rootless container. A container without root has no more privileges than the user who launched it; in the container, this user has root privileges. You can also use command line flags to add privileges to your containers in a granular way.
What about performance?
One area where Docker is ahead of Podman is performance, at least according to some. Although there is little concrete information about it, it is not difficult to find frustrated developers on Hacker News, Stack overflowand Reddit complain about Podman’s performance, especially when running without root. Some Swedish university students ran a test suite on several different container platforms and found Podman missing, although it is admittedly an old pre-1.0 version of Podman. Although there isn’t much technical information on this topic, Podman is anecdotal about his performance.
Will Podman replace Docker?
From the discussion so far, it doesn’t seem like a big change of mood is afoot to replace Docker with Podman. But a major change is coming that will displace Docker from one of its long-standing niches: Kubernetes itself.
Kubernetes and Docker have been the twin giants of the container world for years. But their coexistence has always been somewhat difficult. The rise of Kubernetes came after Docker was well established in its niche. Indeed, one could say that Kubernetes became popular in part because Docker was not up to the task of managing all the containers that needed to be coordinated in a large distributed application. .
Docker (the company) developed its own container orchestration platform in 2015, called Swarm, which was designed to play to the strengths of Docker. Swarm was launched with great fanfare, but never quite caught up with Kubernetes. While Swarm still has followers, Kubernetes has become the de facto standard for container orchestration, just as Docker has become the de facto standard for other aspects of the container ecosystem.
Also, Docker has never really played well with Kubernetes in terms of container execution, the low-level component of the container engine that, among other tasks, works with the underlying operating system (OS) kernel and mounts individual container images. Both Docker and Kubernetes conform to the OCI Image Specification, which Kubernetes uses to coordinate images built for containers. But Kubernetes also relies on compatible container runtimes with a standardized plugin API called Container runtime interface (CRI), which Docker never managed to implement.
For a long time, the popularity of Docker forced Kubernetes to use Dockershim, an CRI-compliant layer that acted as an intermediary between Kubernetes and the Docker daemon. It’s always been kind of a hack, though, and earlier this year Kubernetes discontinued support for Dockershim. (Podman, on the other hand, uses the compatible CRI-O runtime environment of the Cloud Native Computing Foundation.)
It’s part of a larger story about Docker trying and failing to become a business. In short, Docker has never been able to fully break away from Kubernetes. Kubernetes, on the other hand, no longer needs Docker like it used to.
It’s unclear if Podman will replace Docker, but it will definitely be one of the contenders. It helps that Podman isn’t a flagship looking to be monetized, but rather a one-off, open-source tech offering from a much bigger company. We can expect Podman and Kubernetes to stick together for some time to come.
Which container engine should you use?
Hopefully this discussion gives you an idea of the factors that will help you choose between these two container engines. Podman is based on a more secure architecture, while Docker has a deeper history. Podman is native to Kubernetes, while Docker also works with Docker Swarm. Docker includes all the features you need for many container-related tasks. Podman is modular and lets you experiment with different tools for different purposes.
That said, the “Podman versus Docker” question is on some level a false choice. Both platforms create images that conform to the OCI specification, and both are driven by many of the same commands, so you can move seamlessly between the two. You may, for example, want to use Docker for local development and then use Podman for deploy the containers you created in Kubernetes.
One feature that sets Docker apart is that it comes with paid support. But even that has a downside: as Docker (the company) tries to monetize its flagship offering, it has started Docker Desktop development environment billing. Red Hat, on the other hand, seems content to leave Podman free (as in beer) for now.
Jacqueline Primavera is a technical writer and editor in Los Angeles.
Copyright © 2022 IDG Communications, Inc.