What’s Podman? The container engine changing Docker

Podman is a container engine—a software for growing, managing, and operating containers and container pictures. 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 software code and supporting libraries. Container-based functions have revolutionized software program improvement over the previous decade, making distributed and cloud-based programs straightforward to deploy and keep.

Podman is a mission from Purple 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 present.

Podman and Kubernetes

In the event you’re even barely accustomed to container-based improvement, you may know the identify Kubernetes. As containerized functions grew extra complicated, builders wanted instruments that would coordinate containers that interacted with one another whereas operating on completely different digital machines, and even on completely different bodily machines. Such a software is known as 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 necessary 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 be centered on the thought of a pod, as its identify implies. A Podman pod additionally consists of 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 certainly one of Purple Hat’s objectives 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 nearly definitely 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 customary 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 don’t seem to be the identical, and so they have completely 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 tasks for sure functions—as an illustration, it depends on Buildah to construct container pictures.

There are additionally architectural variations: Docker has no native idea of pods, as an illustration. One other necessary distinction is that Docker depends on a repeatedly operating background daemon program to create pictures and run containers, whereas Podman launches containers and pods as separate little one processes. This side of Docker’s design has necessary 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 could be attributed to adherence to open requirements. As a result of each engines work with containers that conform to the OCI customary, you’ll be able to 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 grow to be part of many builders’ programming routines and muscle reminiscence. So as 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 attainable. They went as far as to make it attainable 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? Properly, one necessary 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, but it surely does imply that it’s a must to put some thought into navigating Docker safety points.

In some conditions, you may need to run a container with root privileges on its host machine, and Podman helps you to try this. However in case you would quite maintain your containers safely restricted to consumer area, you are able to do that as effectively, by operating what’s referred to as a rootless container. A rootless container has no extra privileges than the consumer that launched it; inside the container, that consumer has root privileges. You can even use command-line flags so as to add privileges to your containers in a granular method.

What about efficiency?

One space the place Docker has a leg up on Podman is efficiency, a minimum of in keeping with some. Whereas there’s little concrete data on this topic, it is not exhausting to search 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 completely different container platforms and discovered Podman missing, although this was admittedly an older pre-1.0 model of Podman. Whereas there’s not a number of technical data on this subject, anecdotally Podman will get dinged for its efficiency.

Will Podman substitute Docker?

From the dialogue up to now, it might not sound like every nice vibe shift is within the works to interchange Docker with Podman. However a serious change is coming that can displace Docker from certainly one of 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 may say that Kubernetes grew to become standard 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 software.

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 grow to be the de facto customary for container orchestration, simply as Docker grew to become the de facto customary for different elements of the container ecosystem.

Moreover, Docker by no means fairly performed good with Kubernetes by way of its container runtime, the low-level part of the container engine that, amongst different duties, works with the underlying working system (OS) kernel and mounts particular person container pictures. Each Docker and Kubernetes conform to the OCI picture spec, which Kubernetes makes use of to coordinate pictures constructed to containers. However Kubernetes additionally depends on container runtimes appropriate with a standardized plugin API referred to 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, nonetheless, and earlier this 12 months, Kubernetes jettisoned help for Dockershim. (Podman, against this, 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 grow to be an enterprise firm. In brief, Docker was by no means totally capable of 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 substitute Docker is unclear, however it would positively be one of many contenders. It helps that Podman shouldn’t be a flagship product seeking to be monetized, however quite a single open supply know-how providing from a a lot bigger firm. We are able to count on Podman and Kubernetes to stay intertwined for a while to come back.

Which container engine do you have to use?

Hopefully, this dialogue provides you a way of the elements that will help you select between these two container engines. Podman relies on a safer structure, whereas Docker has a deeper historical past. Podman is native to Kubernetes, whereas Docker additionally works with Docker Swarm. Docker consists of all of the performance you want for a lot of container-related duties. Podman is modular and allows you to experiment with completely different instruments for various functions.

With that mentioned, the “Podman vs. Docker” query is on some stage a false selection. Each platforms create pictures that conform to the OCI spec, and each are pushed by lots of the identical instructions, so you’ll be able to transfer seamlessly between the 2. You could, as an illustration, need to use Docker for native improvement, then use Podman to deploy the containers you constructed inside Kubernetes.

One function 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 setting. Purple Hat, alternatively, appears content material to go away Podman free (as in beer) for now.

Jacqueline Primavera is a technical author and editor in Los Angeles.