Containers

A container is a sandboxed runtime environment on Linux systems. The sandbox is constructed using the utilities present in the Linux kernel. Software running in this sandbox share the kernel with the host it is running on, but the certain aspects of kernel that store the machine state are abstracted through namespaces to allow the isolated or the container environments to have a different state than the host even though they are sharing the same kernel.

As you may or may not heard of containers in MacOS¹ and Windows². Windows and macOS run Linux containers by using a lightweight virtual machine in the background to provide the features only Linux kernel can offer.

The contents of the filesystem are typically provided by an image file and the environment exists as a chroot process in the filesystem. The network stack inside the container is constructed with the Linux network stack primitives to share a connection with the host without worrying about conflicting port numbers.

Containers should aim to preserve the normal system interface while changing what resources the software can see and access in a way that the software running in the sandbox should not recognize it is in a sandbox. The The software should run just as it would run natively on a host.

Architecture

A Container Runtime sits between the containers and the host. It uses the primitives found on the host to create the containers. Detailed architecture is available at Containers Architecture

The running container/s could be a single, multiple, group/s (pod/s) of multiple containers.

Containers, images, and registries

To create a container, a container image is used.

Mainstream Container Technologies

There were countless container technologies with fundamentally different architectures for Linux. As the industries evolved, only few left alive. Docker and Podman became the main stream.

Docker

Docker uses a daemon-based model (dockerd). It manages containers and related using the persistent background server (daemon) called docker. And this daemon-based model design makes the container lifecycle management straightforward but, at the same time, creates a single point of failure. If the daemon stops, every container it manages stops with it. The daemon usually runs with root privileges, which then raises security considerations in environments with strict compliance requirements.

Podman

Podman uses a fork-exec model. It manages containers by a two step process (fork-exec) that clones the existing process (called the parent) and overwrites it with a new program. It offers a way to run a container as a simple process like anything other without the need for a daemon or root. It primarily relies heavily on systemd and libpod library. Podman’s daemonless and inclusive architecture makes it an accessible, security-focused option for container management.

Comparison

When we compare Docker and Podman, Docker is the first mover who’s blessed with the network effect and Podman is the second mover who is blessed by the awarness of the first mover’s mistakes.

Backstory

In 2013, Docker came and revolutionized how software was built and deployed. As Docker grew, it began adding features directly into the core engine (such as Swarm) which was opposed and resisted by the community, particularly, CoreOS, a company that specialized in building minimal, highly secure Linux operating systems for running containers at scale, So CoreOS designed Rkt with a fundamentally different architecture. It was what introduced the no-daemon architecture that can directly integrate with Linux init systems (especially well with systemd). This act fragmented the enter container ecosystem therefor, the Open Container Initiative (OCI) under the Linux Foundation formed that managed to get pieces from both the Docker and Rkt to build a standard called OCI standards that all containarization technologies follow now. Redhat acquired CoreOS in 2018 for a quater billion dollars. They created Podman out of the daemon less philosophy of Rkt owned by the CoreOS acquisation and the user friendly CLI of Docker. It gave podman the characteristics of Rootless by default, Daemonless architecture, and First-Class Pods (a concept borrowed from kubernetes) .

Analogy

While both tools share a similar feature set. Docker often resists structural changes to maintain backward compatibility whereas Podman freely adopts to modern needs.

legacy systems where migration is practically impossible, Docker remains the only solution.

Moving forward, this resource will focus primarily on Podman and rpm based operating systems. We hope to introduce support for other platforms down the road. :heart: