Podman Vs. Docker

What are these services? Why use any of them? Which is better and why? Read on to find out the answers to all these questions in this over-explored topic.

Podman Vs. Docker

Prelims

Virtual Machines vs. Containers

The First Battle

Before we discuss the differences between Podman and Docker we should first cover the differences between a virtual machine and a container. While they are both technologies that create virtual instances of computer hardware to separate applications from IT structure, the way they achieve this is very different.

Virtual Machines

Virtual machines started in the 1960's with IBM's creation of the CP-67 mainframe running CP-CMS (Control Program - Console Monitor System). The idea of the CP-67 system was that the CP ran on the mainframe which created virtual machines which ran the CMS; which the user can interact with. Having this feature allowed multiple people to work different batches on one machine through virtualization.

A virtual machine is a digital instance of a physical machine that hosts an entire operating system. It is demanding when it comes to hardware resources in comparison to containers but they offer a high level of isolation which is beneficial to security. VMs are helpful with managing a large number of services and complex workloads.

Containers

Containers also have a long history with the first semblance of a container coming up in 1979 with Unix V7 when the chroot system call was introduced. This changed the root directory of a process and its children to a new location in the filesystem. This advance was the beginning of process isolation: segregating file access for each process.

Containers are a packaged version of a software that contain all of an application's code, libraries, and dependencies. They are more lightweight and portable than virtual machines and are a good choice for applications that need quick and easy deployments with optimized computing.

Images are the main way Docker and Podman create templates for the containers to be reproduced across different systems. Images are a read-only template with instructions for creating a container.

Are you ready to RUMBLE?

Now that we've covered what a container is and why developers might use them, let's explore the two biggest container engines and what differences exist between them.

The Main Event

Podman vs. Docker

Docker

Backstory

Docker is a platform written in the Go programming language that provides tooling and management for the lifecycle of container(s). It takes advantage of a technology called namespaces to create isolated workspaces called containers. Namespaces provide isolation as each part of a container runs in a separate namespace and its access does not go out of the bounds of that namespace. Docker debuted in Santa Clara at PyCon in 2013. It was originally released as open-source in March of 2013 and used LXCs (Linux Containers) as its default execution environment. Being in the open-source space for over a decade now has given the engine a lot of time to develop grow and receive support from many other development platforms and applications.

What makes up the Docker architecture?

It uses a client-server architecture where the Docker client communicates to the Docker daemon. The daemon is responsible for building, running, and distributing the containers. Both daemon and client can either run on the same system or you can connect the a client to a remote daemon. They communicate to each other using a REST API over UNIX sockets or a network interface. Another Docker client is Docker Compose, that lets you work with applications consisting of multiple containers.

Docker Daemon

The Docker daemon (dockerd) is always checking for API requests and manages the containers, images, networks, and volumes. The daemon can also communicate with other daemons to manage more services.

Docker Client

The Docker client (docker) is the main way that users work with Docker. Running commands such as docker run, docker build, and docker pull are instructions sent to dockerd which then carries it out.

Docker Registries

The registry is where Docker stores images. Docker Hub is a public online registry that is available for use by all, but you can host your own private registry as well. In Docker, you can create your own image with a Dockerfile or pull an image down make alterations and rebuild it with the changes. Once created, you can push this image up to Docker Hub or whichever service you are using to host your images.


Podman

The Villain Arc

Podman began as a project at Red Hat and was released as an open source project in April of 2018. Red Hat was also at the PyCon in 2013 but they were not releasing innovative containerization technology at that time. The project was originally called kpod but was renamed to Podman for POD MANager when it was released.

Podman "Arc"hitecture

Podman is daemonless which means it does not rely on a process with root privileges to run containers. Daemons often require root user privileges which can cause a security concern if a container were to be compromised. Since Podman does not use a daemon it uses systemd which is a system and service manager for Linux operating systems.

Since Podman is very modular, it utilizes tools such as Skopeo and Buildah to build and move its containers. Skopeo moves container images between different types of storage systems allowing you to copy image between registries like docker.io, quay.io, and your internal registry or between different storage types on your own system. Buildah builds containers either from scratch or from an image. Podman, Skopeo, and Buildah are to containers like a socket wrench, crowbar, and lift are to a car, all parts of a toolkit necessary to fix a car with varying levels of importance and utilization.

Other than the differences in privileges and daemon, Docker and Podman share a similar architecture with image repositories that can be self-hosted and a client interface through either the command line or a GUI (graphical user interface) to communicate with the engine.

rootless

By removing the need of interacting with a root-owned daemon, Podman allows for rootless containers that can be created, run and manage without requiring admin privileges. This makes the container environment more accessible and reduces security risks. Podman containers also launch with a Security-Enhanced Linux (SELinux) label, giving admins more control over what resources and capabilities are provided to container processes.


What's the difference?

  • Rootless: Podman is rootless while Docker only recently added a rootless mode to its daemon configuration.
  • Modularity: Docker is an all-in-one tool for container creation and management whereas Podman utilizes tools such as Buildah and Skopeo for a more specialized approach to containerization.
  • Daemon: Docker uses a daemon, dockerd, that requires root privileges. Podman uses the already existing systemd to manage its containers and does not need admin access.

My 2¢

Docker has always been the go-to option for me in my home lab setup as it is very plug-and-play. I believe one of the benefits of the dockerd daemon is that it requires root access, this makes configuring a container's access much easier since it has access to everything. Oftentimes in my experience with Podman I find myself managing permissions and access more than I manage creation and design of the containers.

However, IBM is taking large strides with its suite of software as they now own Red Hat, Podman, Terraform, and plenty of other industry standard tools. Podman is now the only fully supported form of containerization on Red Hat Enterprise Linux 8 (RHEL 8) and later. Luckily, Podman's commands nearly mirror those of Docker so the learning gap between the two is microscopic.


Sources

  • https://docs.docker.com/get-started/docker-overview/
  • https://www.redhat.com/en/topics/containers/what-is-podman
  • https://www.aquasec.com/blog/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016/#:~:text=2008%3A%20LXC,kernel%20without%20requiring%20any%20patches.
  • https://www.inventivehq.com/history-of-virtualization/