Podman is a container engine—a instrument for creating, managing, and operating containers and container photographs. Containers are standardized, self-contained software program packages that maintain all the weather essential to run anyplace with out the necessity for personalization, together with utility code and supporting libraries. Container-based purposes have revolutionized software program improvement over the previous decade, making distributed and cloud-based techniques simple to deploy and preserve.
Podman is a mission from Crimson Hat that’s open supply and free to obtain. It’s a relative newcomer to the containerization scene, with model 1.0 being launched in 2019. Podman has since made nice strides, and its rise has been compounded by the gradual decline of Docker, the mission that in some ways created the world of containers as we all know it at the moment.
Podman and Kubernetes
For those who’re even barely accustomed to container-based improvement, you will know the identify Kubernetes. As containerized purposes grew extra advanced, builders wanted instruments that would coordinate containers that interacted with one another whereas operating on totally different digital machines, and even on totally different bodily machines. Such a instrument is named a container orchestration platform, and Kubernetes is by far probably the most distinguished instance. Kubernetes can work with any container that meets the Open Container Initiative (OCI) picture specification, which Podman’s containers do.
One of many vital options of Kubernetes is the idea of a pod, an ephemeral grouping of a number of containers that’s the smallest unit of computing that Kubernetes can handle. Podman can also be centered on the thought of a pod, as its identify implies. A Podman pod additionally contains a number of containers, that are grouped collectively in a single namespace, community, and safety context. This similarity makes Podman and Kubernetes a pure match, and from the start one among Crimson Hat’s targets was to have Podman customers orchestrate containers with Kubernetes.
Podman vs. Docker
The opposite large identify from the world of containers that you’ve got virtually actually heard is Docker. Docker wasn’t the primary container engine however in some ways it has come to outline containerization. A lot of how Docker works is the de facto normal for container-based improvement—sufficient in order that many individuals use “Docker” as a shorthand for containers.
Whereas Docker and Podman occupy an identical area within the container ecosystem, they aren’t the identical, and so they have totally different philosophies and approaches as to how they work. As an illustration, Docker is an all-in-one platform with instruments for particular duties, whereas Podman collaborates with different initiatives for sure functions—as an example, it depends on Buildah to construct container photographs.
There are additionally architectural variations: Docker has no native idea of pods, as an example. One other vital distinction is that Docker depends on a constantly operating background daemon program to create photographs and run containers, whereas Podman launches containers and pods as separate little one processes. This side of Docker’s design has vital implications for safety, which we’ll talk about shortly.
Docker instructions on Podman
By design and necessity, Podman and Docker are general appropriate. A part of that compatibility may be attributed to adherence to open requirements. As a result of each engines work with containers that conform to the OCI normal, you possibly can create a container with Docker and modify it in Podman, or vice versa, then deploy both container onto Kubernetes.
When Podman rolled out in 2019, Docker was so dominant that its command-line interface had turn into part of many builders’ programming routines and muscle reminiscence. With a purpose to make a possible transfer to Podman extra seamless, Podman’s creators made positive that its instructions and syntax mirrored Docker’s as a lot as potential. They went as far as to make it potential to set an alias that re-routes Docker instructions to Podman.
Higher safety with rootless containers
With Podman and Docker working so equally in so some ways, why would you select one over the opposite? Nicely, one vital motive is safety. Keep in mind how Docker depends on a daemon to do a lot of its ongoing work? That daemon runs as root, which makes it a possible entry level for attackers. This is not an insurmountable impediment to safe computing, nevertheless it does imply that you need to put some thought into navigating Docker safety points.
In some conditions, you will wish to run a container with root privileges on its host machine, and Podman allows you to do this. However if you happen to would slightly maintain your containers safely restricted to person area, you are able to do that as effectively, by operating what’s known as a rootless container. A rootless container has no extra privileges than the person that launched it; inside the container, that person has root privileges. You too can use command-line flags so as to add privileges to your containers in a granular manner.
What about efficiency?
One space the place Docker has a leg up on Podman is efficiency, not less than in line with some. Whereas there’s little concrete info on this topic, it is not onerous to seek out annoyed builders on Hacker Information, Stack Overflow, and Reddit complaining about Podman’s efficiency, particularly when it is operating rootless. Some Swedish college college students ran a benchmark suite on a number of totally different container platforms and discovered Podman missing, although this was admittedly an older pre-1.0 model of Podman. Whereas there’s not a variety of technical info on this matter, anecdotally Podman will get dinged for its efficiency.
Will Podman change Docker?
From the dialogue to this point, it might not sound like several nice vibe shift is within the works to interchange Docker with Podman. However a serious change is coming that can displace Docker from one among its longtime niches: Kubernetes itself.
Kubernetes and Docker have for years been the dual giants of the container world. However their coexistence was at all times considerably uneasy. The rise of Kubernetes got here after Docker was effectively established in its area of interest—certainly, you can say that Kubernetes turned widespread partly as a result of Docker wasn’t as much as the duty of managing all of the containers that wanted to be coordinated in a big, distributed utility.
Docker (the corporate) developed its personal container orchestration platform in 2015, dubbed Swarm, that was designed to play to Docker’s strengths. Swarm was launched with nice fanfare, however by no means fairly caught as much as Kubernetes. Whereas Swarm nonetheless has devotees, Kubernetes has turn into the de facto normal for container orchestration, simply as Docker turned the de facto normal for different features of the container ecosystem.
Moreover, Docker by no means fairly performed good with Kubernetes by way of its container runtime, the low-level element of the container engine that, amongst different duties, works with the underlying working system (OS) kernel and mounts particular person container photographs. Each Docker and Kubernetes conform to the OCI picture spec, which Kubernetes makes use of to coordinate photographs constructed to containers. However Kubernetes additionally depends on container runtimes appropriate with a standardized plugin API known as the Container Runtime Interface (CRI), which Docker has by no means gotten round to implementing.
For a very long time, Docker’s reputation pressured Kubernetes to make use of Dockershim, a CRI-compliant layer that was an middleman between Kubernetes and the Docker daemon. This was at all times one thing of a hack, nevertheless, and earlier this 12 months, Kubernetes jettisoned help for Dockershim. (Podman, in contrast, makes use of the appropriate CRI-O runtime from the Cloud Native Computing Basis.)
That is half of a bigger story about Docker attempting and failing to turn into an enterprise firm. In brief, Docker was by no means totally in a position to break free from Kubernetes. Kubernetes, in the meantime, now not wants Docker to the extent it as soon as did.
Whether or not Podman will change Docker is unclear, however it is going to positively be one of many contenders. It helps that Podman just isn’t a flagship product trying to be monetized, however slightly a single open supply know-how providing from a a lot bigger firm. We will count on Podman and Kubernetes to stay intertwined for a while to come back.
Which container engine must you use?
Hopefully, this dialogue provides you a way of the components that will help you select between these two container engines. Podman is predicated on a safer structure, whereas Docker has a deeper historical past. Podman is native to Kubernetes, whereas Docker additionally works with Docker Swarm. Docker contains all of the performance you want for a lot of container-related duties. Podman is modular and allows you to experiment with totally different instruments for various functions.
With that stated, the “Podman vs. Docker” query is on some stage a false alternative. Each platforms create photographs that conform to the OCI spec, and each are pushed by lots of the similar instructions, so you possibly can transfer seamlessly between the 2. It’s possible you’ll, as an example, wish to use Docker for native improvement, then use Podman to deploy the containers you constructed inside Kubernetes.
One characteristic that units Docker aside is that it comes with paid help. However even this has a flipside: as Docker (the corporate) tries to monetize its flagship providing, it has began charging for the Docker Desktop improvement atmosphere. Crimson Hat, alternatively, appears content material to depart Podman free (as in beer) for now.
Jacqueline Primavera is a technical author and editor in Los Angeles.
Copyright © 2022 IDG Communications, Inc.
