Shipping containers work all over the world because everyone agreed on one set of sizes and one kind of lock. A crane in any port can lift a box that was loaded in any other country, and nobody has to know who packed it. Electrical plugs and sockets work the same way: any appliance with the right plug fits any socket that follows the same standard. The Open Container Initiative (OCI) is that kind of agreement for software containers. If a tool follows the agreed format, it can build, move, or run what another tool made.

Here is how that agreement came about.

In 2015, the container ecosystem faced a major risk of fragmentation.

Docker was the dominant container engine, but competing vendors and cloud providers began creating rival container formats and execution runtimes (such as CoreOS's rkt and appc specification). rkt was a container runtime from the company CoreOS, and appc (App Container) was CoreOS's own written format for container images, a rival to Docker's.

If every cloud vendor required a different image format or runtime engine, developers would be trapped rebuilding separate container packages for every cloud infrastructure target.

To prevent vendor lock-in and standardize container primitives, tech leaders formed the Open Container Initiative (OCI) under the Linux Foundation. Vendor lock-in means being stuck with one company's product because switching away from it costs too much. The Linux Foundation is a non-profit organization that hosts open-source projects, and the OCI is an industry group it hosts that writes shared, public rules (specifications) for containers.

The OCI maintains three open standards. This article covers the first two in depth and names the third at the end:

1. The OCI Image Specification (Image-Spec): Defines how container images are formatted, stored, content-addressed, and archived on disk or in registries. Content-addressed means a file is named by a fingerprint of its contents instead of a name someone chose. A registry is a server that stores container images and hands them out on request (Docker Hub is one).
2. The OCI Runtime Specification (Runtime-Spec): Defines how an unpacked container bundle is executed on a host system by a low-level runtime (such as runc).
3. The OCI Distribution Specification (Distribution-Spec): Defines the HTTP API (the agreed set of web requests) that tools use to push images to a registry and pull them back down. It appears again in the table near the end.

Understanding the first two specifications explains how any OCI-compliant runtime (like runc, crun, or gVisor) can execute an image built by Docker, Podman, or BuildKit. Compliant means it follows the specification. crun is a runtime written in C, and gVisor is a Google project that provides an OCI runtime (runsc) which adds an extra layer of isolation between the application and the host operating system. Podman is a container tool that, like Docker, can build and run containers, but it does not need a background daemon (a program that keeps running in the background and waits for commands). BuildKit is the build engine Docker uses to turn a Dockerfile into an image. Because the builder and the runner both read the same file layout, they do not need to know anything about each other.

1. The OCI Image Specification

Think of an image as a recipe box. It has a table of contents (the index), a card listing the parts of one recipe (the manifest), a card with the cooking settings (the config), and the ingredient bags (the layers).

An OCI container image is not a virtual machine disk image (a VM disk image is a full copy of a whole computer's disk, and an image is not that). It is an archived tarball containing a set of cryptographic, content-addressable JSON files and tar compressed layer diffs.

A tarball is a single file that packs many files and folders together, like a zip file (the tar tool does the packing, and gzip is a separate step that compresses the result). A layer is one step's worth of file changes in an image, and a layer diff is just the files that were added, changed, or removed in that step. Stacking the layers in order gives the full set of files.

Two terms appear throughout this section. SHA-256 is a fingerprint function: it turns any file into a fixed 64-character code, and a different file gives a different code. That code is called a digest. A blob is simply a file stored under the name of its digest.

When you inspect an OCI image layout on disk, you find three top-level entries (index.json, oci-layout, and the blobs/ folder), and inside blobs/sha256/ four blobs that hold the real content:

[ OCI Image Layout Structure ]
├── index.json               <-- Image Index (List of manifests for multi-arch support)
├── oci-layout               <-- Layout version identifier ({"imageLayoutVersion": "1.0.0"})
└── blobs/
    └── sha256/
        ├── e3b0c44298fc1c... <-- Image Manifest JSON
        ├── 7a8b9c1d2e3f4a... <-- Image Configuration JSON
        ├── 1a2b3c4d5e6f7a... <-- Layer 1 tar.gz payload
        └── 9f8e7d6c5b4a3f... <-- Layer 2 tar.gz payload

The long hex names are the digests (the fingerprints) of each file, and the hashes in these examples are shortened or made up to illustrate the layout. Multi-arch means one image name that has separate builds for different processor types, such as Intel/AMD (amd64) and ARM (arm64). The index is what lists those builds. The oci-layout file only records which version of the layout format the folder uses.

A. The Image Index (index.json) and the Image Manifest (Manifest Blob)

The index (index.json) lists manifests, one for each platform build of an image. Each manifest lists one image's config and layers.

The Image Manifest acts as the entry point for an image version tag (e.g., nginx:latest). A tag is a human-readable label for one version of an image, so nginx:latest means the image named nginx with the tag latest. The manifest links the image configuration JSON file to its underlying filesystem layers:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:7a8b9c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b",
    "size": 1472
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b",
      "size": 2814021
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e",
      "size": 1420102
    }
  ]
}

Notice that every referenced file is identified by its SHA-256 Digest. If a layer's contents change by a single byte, its SHA-256 digest changes, enforcing immutable content-addressable storage. Immutable means it cannot be changed. If anyone alters a file, its fingerprint no longer matches the one written in the manifest, so the change is detected, and the same file can safely be shared between many images.

Here is what each key in the manifest means:

• schemaVersion is the version of the manifest format. It is always 2 for current manifests.
• mediaType at the top says what kind of document this file is (an OCI image manifest). Everywhere else in the file, mediaType says what kind of file the entry points to: a config JSON, or a gzip-compressed tar layer.
• config points to the Image Configuration JSON blob.
• layers is the list of layer blobs, in the order they are stacked.
• digest is the SHA-256 fingerprint of the file being pointed to, which is also its name under blobs/sha256/.
• size is the length of that file in bytes.

B. The Image Configuration JSON

While layers store the filesystem files, the Image Config JSON defines execution metadata (data about how to run the image, not part of its files) for the target runtime:

{
  "architecture": "amd64",
  "os": "linux",
  "config": {
    "Env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin", "NGINX_VERSION=1.25.1"],
    "Cmd": ["nginx", "-g", "daemon off;"],
    "WorkingDir": "/",
    "ExposedPorts": { "80/tcp": {} }
  },
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:c2ad4e0... (Uncompressed Layer 1 SHA)",
      "sha256:e8f1b2a... (Uncompressed Layer 2 SHA)"
    ]
  }
}

The hashes here are placeholders. Here is what the keys mean:

• architecture is the processor type the image was built for. amd64 is the 64-bit Intel/AMD type.
• os is the operating system the image expects.
• Env sets environment variables, which are named settings a program can read. PATH is the list of folders the system searches when you type a command name.
• Cmd is the command to run when the container starts. In "daemon off;", a daemon is a program that detaches and keeps running in the background. This nginx setting tells nginx to stay in the foreground instead, because a container exits when its main process exits. (This is nginx's own use of the word, not Docker's daemon.)
• WorkingDir is the folder the command starts in.
• ExposedPorts records that the program listens on port 80 over TCP. It is a note for people and tools, and does not open the port by itself.
• rootfs lists the layers. Each entry in diff_ids is the SHA-256 of one layer after it has been uncompressed.

That last point means each layer has two different fingerprints. The digest in the manifest is the fingerprint of the compressed file (the tar+gzip blob that is stored and downloaded). The diff_ids entry in the config is the fingerprint of the same layer's tar once uncompressed, which is what matters after you unpack it.

2. The OCI Runtime Specification & Filesystem Bundle

The image is the packed, stored form, like a zipped game. The bundle is the unpacked, ready-to-launch form: the game's installed folder plus its launch settings.

While the Image Spec governs static image archives, the OCI Runtime Specification governs how a container is executed at runtime.

To execute a container, an OCI-compliant runtime like runc requires an OCI Filesystem Bundle. A filesystem is the organized tree of files and folders on a disk. Part 2 followed the chain containerd, then the shim, then runc, and said the shim hands runc an OCI bundle. This part opens that bundle.

An OCI Bundle is a simple directory on disk containing exactly two things:

[ OCI Bundle Directory ]
├── config.json         <-- Execution configuration required by runc
└── rootfs/             <-- Unpacked root filesystem directory

rootfs/ is the folder the container will see as its entire disk, holding /bin, /etc, and so on. The layers from the image, unpacked and stacked, end up here.

The config.json Runtime Contract

When containerd unpacks an OCI image for runc, it reads the Image Config JSON and translates it into an OCI Runtime config.json.

This is the step where the stored form (the image) becomes the runnable form (the bundle). Recapping Part 2: containerd fetches the image's files and manages the container, the shim stays beside the container and calls runc, and runc reads the bundle to set up and start the process. The translation maps image settings to runtime settings. Image Cmd becomes process.args, image Env becomes process.env, and image WorkingDir becomes process.cwd. ExposedPorts has no counterpart here, because networking is set up by the container engine and not by this file.

This file does not name system calls. It lists the settings runc uses when it asks the Linux kernel to isolate and start the process. The kernel is the core of the operating system, and a system call is a request a program makes to it. The spec describes the file as the container's process, its root filesystem, mounts, namespaces, cgroup resource limits, capabilities, and more:

{
  "ociVersion": "1.0.2",
  "process": {
    "terminal": false,
    "user": { "uid": 0, "gid": 0 },
    "args": ["nginx", "-g", "daemon off;"],
    "env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"]
  },
  "root": {
    "path": "rootfs",
    "readonly": true
  },
  "linux": {
    "namespaces": [
      { "type": "pid" },
      { "type": "network" },
      { "type": "ipc" },
      { "type": "uts" },
      { "type": "mount" }
    ],
    "resources": {
      "memory": { "limit": 536870912 }
    }
  }
}

Here is what each part of the file means. This example is shortened, and the spec also requires a process.cwd entry in a full file.

• ociVersion is the version of the Runtime Spec the file follows.
• process is what to run and as whom. terminal: false means no terminal is attached. user gives the user and group numbers (uid and gid), where 0 is the all-powerful root user. args is the command line to start, and env is its environment variables.
• root is the folder to use as the container's disk. readonly: true means the container cannot write to it.
• linux.namespaces are the private views to create. A namespace gives the process its own view of one thing: pid is its own process list, network its own network, ipc its own inter-process messaging, uts its own hostname, and mount its own set of mounted filesystems.
• linux.resources.memory.limit is the cgroup memory cap in bytes. A cgroup is a kernel feature that caps resources such as memory for a group of processes. $512 \times 1024 \times 1024 = 536{,}870{,}912$ bytes, which is 512MB.

Part 2 showed the shim calling runc create, which sets up the container without running your program yet. runc start then runs it. runc run does both in one command: it creates the container and starts it. That is why the line below says run.

When you invoke runc run my-container, runc parses this config.json file, configures the requested Linux namespaces and cgroup memory limits (536870912 bytes = 512MB), enters rootfs, and executes execve("nginx"). As in Part 2, execve swaps the current process for the nginx program.

OCI Architectural Decoupling Matrix

Decoupled means each part can be swapped for another without changing the others. A protocol is an agreed way for two programs to talk. In the table, the middle column is the spec, and the third column names example tools that implement it. runc is the reference runtime for the Runtime Spec, and distribution/distribution (the CNCF Distribution project) is the reference registry for the Distribution Spec. BuildKit and Docker Engine are widely used tools that produce OCI images, not reference implementations.

Summary

The Open Container Initiative standardizes containerization across vendor ecosystems. In short, the Image Spec is how a package is stored and labeled, and the Runtime Spec is how an unpacked package is started:

• OCI Image Spec defines content-addressable manifests, configuration JSON, and tarball layer diffs.
• OCI Runtime Spec defines the filesystem bundle (config.json + rootfs/) passed to low-level runtimes.
• runc reads the OCI bundle configuration to configure namespaces and cgroups before executing the target binary.

You log into a production host (the computer, often a remote Linux server, that runs your containers) and execute a simple command:

docker run -d --name web-server -p 80:80 nginx

The flags are small instructions to Docker. -d runs the container in the background so your terminal is free again. --name web-server gives the container a name you can use later. -p 80:80 forwards port 80 on the host to port 80 inside the container (a port is a numbered doorway for network traffic, and web servers listen on port 80 by default). nginx is the image to run, and Nginx is a widely used web server program.

The command returns a 64-character container ID, and Nginx starts serving web traffic.

Later, an engineer performs a rolling software update on the Docker system daemon:

systemctl restart docker

systemctl is the Linux command that starts, stops and restarts background services, and this one restarts the Docker background program. A daemon is a program that runs in the background with no window, waiting for requests. dockerd is the daemon that does Docker's work.

While the dockerd daemon restarts, not a single HTTP request to the running Nginx container drops. The web server keeps running uninterrupted.

How does Docker restart its main control daemon without killing active running containers?

To answer this, we must examine the multi-layered process architecture that executes underneath the docker command line interface (CLI, a program you control by typing commands): CLI to dockerd to containerd to containerd-shim to runc. The answer arrives in the process tree section near the end of this article.

An everyday picture helps. Think of a restaurant. The host who takes your order is the CLI. The manager is dockerd, who sets up the table and the bill. The kitchen lead is containerd, who runs each dish from start to finish. A cook assigned to your table is the shim, and the builder who prepares the cooking station and then leaves is runc. If the manager goes home, the cook who is already cooking your dish keeps going. Each name in the chain is a separate program that hands work to the next one, and the rest of the article walks down that chain.

The Architecture of the Process Chain

Modern Docker is not a single monolithic process. It is a collection of modular tools connected via UNIX sockets and gRPC interfaces.

A UNIX socket is a special file that two programs on the same machine use to send messages to each other. gRPC is a standard way for one program to call another program's functions by sending structured messages. A process is one running program, and every process is started by a parent process.

Read the diagram below from top to bottom. Each box receives a request from the box above it and passes work to the box below it. The paths like /usr/bin/docker show where each program file lives on a Linux disk, and you do not need to memorize them.

[ User Shell ]
      |
      |  docker run nginx
      v
+-------------------------------------------------------------------+
| 1. Docker CLI (/usr/bin/docker)                                   |
+-------------------------------------------------------------------+
      |
      |  HTTP REST API payload over /var/run/docker.sock
      v
+-------------------------------------------------------------------+
| 2. Docker Daemon (/usr/bin/dockerd)                               |
|    - Handles image builds, network bridges, volume management     |
+-------------------------------------------------------------------+
      |
      |  gRPC Requests over /run/containerd/containerd.sock
      v
+-------------------------------------------------------------------+
| 3. containerd Daemon (/usr/bin/containerd)                        |
|    - Manages image snapshots, container lifecycles, content store |
+-------------------------------------------------------------------+
      |
      |  Forks a light daemonless shim process per container
      v
+-------------------------------------------------------------------+
| 4. containerd-shim (/usr/bin/containerd-shim-runc-v2)             |
|    - Holds open stdin/stdout/stderr file descriptors              |
|    - Manages container exit status codes                          |
+-------------------------------------------------------------------+
      |
      |  Executes OCI Bundle
      v
+-------------------------------------------------------------------+
| 5. runc CLI (/usr/bin/runc)                                       |
|    - Sets up Linux namespaces & cgroups via libcontainer          |
|    - Executes entrypoint binary (PID 1)                           |
|    - Replaces itself with that binary (execve), so it is gone     |
+-------------------------------------------------------------------+
      |
      v
+-------------------------------------------------------------------+
| 6. Containerized Process (nginx: master process)                  |
+-------------------------------------------------------------------+

In plain words, the diagram says this:

1. You type docker run nginx. The CLI turns it into a web-style request and sends it through the socket file /var/run/docker.sock.
2. dockerd receives the request. It prepares the parts around the container (images, networking, storage) and then asks containerd to run it, using gRPC over /run/containerd/containerd.sock.
3. containerd manages the container's life: fetching its files and deciding when it starts and stops. For each container it starts one small helper process, the shim.
4. The shim stays beside the container. It keeps the container's input and output connected (stdin is where a program reads input, stdout is where it prints normal output, and stderr is where it prints errors) and records how the container ends. It calls runc to do the actual setup.
5. runc asks the Linux kernel (the core of the operating system) to build the isolated environment, then turns itself into the container's program. Namespaces and cgroups, explained in section 5, are how that isolation is built.
6. The last box is the container's own program, here the Nginx master process, which is the main Nginx process that starts the others.

The shim's real file name is containerd-shim-runc-v2. The containerd-shim in the box title and in the process tree later is the same program, shortened. Tools that list processes often show a shortened name, because Linux keeps only the first 15 characters of a process name, and containerd-shim is exactly 15 characters.

1. Docker CLI (/usr/bin/docker)

The docker command is a client-side Go binary. A binary is a ready-to-run program file, Go is the programming language it was written in, and client-side means it only sends requests and does not do the work itself. It performs no container management or namespace creation itself.

When you type docker run, the CLI translates flags (-d, -p 80:80) into an HTTP JSON payload and transmits it across a local UNIX domain socket at /var/run/docker.sock to the Docker Daemon. HTTP is the request and reply format web browsers use, JSON is a text format for structured data such as {"name": "web"}, and a payload is the data being sent. The socket is a file path standing in for a website address, so the request never leaves the machine:

POST /v1.43/containers/create?name=web-server HTTP/1.1
Host: localhost
Content-Type: application/json

{
  "Image": "nginx",
  "ExposedPorts": { "80/tcp": {} },
  "HostConfig": {
    "PortBindings": { "80/tcp": [{ "HostPort": "80" }] }
  }
}

POST means "create something", and /containers/create names what to create. The v1.43 is the version number of Docker's API, and the name=web-server part comes from your --name flag. An API (application programming interface) is a set of web-style addresses a program exposes so that other programs can ask it to do things, and a REST API is one built in that style. In the body, 80/tcp means port 80 using TCP, the usual protocol for web traffic.

2. Docker Daemon (dockerd)

The dockerd process acts as the high-level orchestrator for host-level container features. In the restaurant picture, it is the manager who sets up everything around the dish:

• Build Engine: Translates Dockerfile instructions into image layers. A Dockerfile is a text recipe of steps for building an image, an image is a read-only package of files plus start settings, and a layer is one step's file changes stacked on the previous ones.
• Virtual Networking: Allocates IP addresses, updates iptables rules, and sets up virtual bridge interfaces (docker0). An IP address is the numeric address that identifies a machine on a network, and each container gets its own. iptables is Linux's built-in list of rules for filtering and routing network traffic. A virtual bridge is a software network switch that connects containers to each other and to the host.
• Volume Management: Mounts host directories or cloud block storage into container paths. Mounting makes a folder or disk appear at a chosen path inside the container, and a host directory is a folder on the real machine.
• REST API Server: Authenticates requests and exposes endpoints.

Once dockerd completes high-level network and storage preparation, it hands off container execution to containerd.

3. containerd

If dockerd is the manager who takes the customer's requirements, containerd is the kitchen lead who runs each dish from start to finish.

containerd is an industry-standard, CNCF-graduated container runtime daemon. CNCF is the Cloud Native Computing Foundation, a non-profit that hosts open-source infrastructure projects, and graduated is its highest maturity level. A container runtime is the software that actually starts and manages containers.

While dockerd handles high-level user features, containerd manages low-level container lifecycle execution:

• Pulling and pushing container images from registries. A registry is a server that stores images for download, and Docker Hub is one.
• Unpacking image layers into root filesystems using OverlayFS snapshotters. A root filesystem is the folder tree that becomes the container's /. OverlayFS is a Linux feature that stacks read-only layers into one combined view, and a snapshotter is the containerd component that prepares that view.
• Managing container execution state (start, stop, pause).

containerd listens on a gRPC socket at /run/containerd/containerd.sock. It can operate completely independent of Docker (for example, Kubernetes uses containerd directly via CRI without dockerd). Kubernetes is software that runs many containers across many machines, and CRI (Container Runtime Interface) is the interface it uses to ask a runtime to start containers.

4. containerd-shim

A shim is a small adapter that sits between two parts. Here it is a tiny babysitter program that stays alive next to one container even if its bosses restart.

When containerd is instructed to start a container, it does not launch the container process directly under its own process tree. Every running program is a process started by a parent process, and together they form a tree. Fork means to create a new child process.

Instead, containerd forks an intermediate process called containerd-shim. The file on disk is named containerd-shim-runc-v2, which is the same program.

Why the Shim Exists:

1. Daemonless Container Execution: The shim acts as the parent process for the container's PID 1. If dockerd or containerd crash or undergo system upgrades, the shim keeps running, keeping the container process alive! A PID is the number Linux gives each process, and PID 1 here means the first process inside the container, the one the container lives and dies with. The parent matters because a process is tied to the one that started it. If the container were a direct child of dockerd, stopping dockerd would leave it orphaned, with no parent left to track it. Because the container's parent is the shim, and the shim is not dockerd, restarting dockerd does not touch the container. This is the answer to the question at the top, and the process tree below shows it.
2. I/O Streaming: Holds open the standard I/O pipes (stdin, stdout, stderr) so logs are captured even if the daemon restarts. Stdin is where a program reads input, stdout is where it prints normal output, stderr is where it prints errors, and a pipe carries that data between programs. Each of these is a file descriptor, a small number a process uses to refer to an open file or pipe.
3. Exit Code Reporting: Waits for the container PID 1 process to terminate and reports its exit code back to containerd. An exit code is the number a program returns when it ends, and 0 usually means success.

5. runc

runc is like the builder who sets up a sealed room (the container), moves the program in, and leaves. It does not stay to supervise.

runc is the reference implementation of the Open Container Initiative (OCI) Runtime Specification. A specification is a written rulebook, and a reference implementation is a program that shows how to follow it. OCI is a group that writes shared standards for containers, and part 3 covers it.

When containerd-shim starts, it invokes runc create passing an OCI Bundle (a directory containing a config.json file and a rootfs/ directory). The config.json file holds the container's settings, and rootfs/ holds the files the container will see as its whole disk.

How runc Creates the Container:

runc translates the settings file into requests to the Linux kernel. Those requests are system calls: the way a program asks the kernel (the core of the operating system) to do something. The (2) after each name is the manual page section number for system calls, and you can ignore it.

1. Reads config.json to extract namespace settings, cgroup limits, capabilities, and environment variables. A namespace gives a process its own private view of one system resource, such as the process list, the network or the files. A cgroup limits how much CPU or memory a group of processes may use. Capabilities are the individual special privileges a process may hold, and environment variables are named settings handed to a program when it starts.
2. Invokes Linux system calls (clone(2) or unshare(2)) to create new namespaces (PID, NET, MNT, UTS, IPC). These are the process IDs, the network, the mounts (what is attached where in the file tree), the hostname, and the messaging between processes. clone creates a new process, and unshare moves the calling process into new namespaces.
3. Configures cgroup resource limits in /sys/fs/cgroup/, a special folder where Linux exposes cgroup settings as files.
4. Executes pivot_root(2) to lock the process into rootfs/. This makes rootfs/ appear as the whole filesystem, so the process cannot see the host's files.
5. Executes execve(2) to replace its own process memory with the target container binary (e.g., nginx). execve swaps the program running in a process for another program, inside the same process.

Crucially, execve(2) does not start a second process. The runc process replaces itself with Nginx, so no runc is left running. Because the same process simply becomes Nginx, runc uses no memory or CPU of its own while the container runs.

Inspecting the Live Process Tree

pstree prints running programs as a family tree. In the command below, pgrep containerd finds containerd's process number and $(...) pastes that number into the command. You can observe this process chain directly on any Linux host using pstree:

$ pstree -plu $(pgrep containerd)
containerd(1042)─┬─containerd-shim(8920)───nginx(8945)───nginx(8990)
                 └─{containerd}(1043)

The shim appears here as containerd-shim, the shortened form of containerd-shim-runc-v2. The line {containerd}(1043) is a thread of containerd, meaning a separate strand of work inside the same process. In the output, the number in parentheses is each process's ID.

Notice the process tree hierarchy:

• containerd (PID 1042) is the parent of containerd-shim (PID 8920).
• containerd-shim is the parent of the nginx master process (PID 8945).
• runc is nowhere in the process tree because it replaced itself with Nginx after setup!
• dockerd is absent from the container process parentage, which is why restarting dockerd does not disrupt Nginx. It handed the job to containerd and only talks to it by message, so it is not a parent of anything here.

Summary & Next Steps

Docker's modular toolchain separates high-level developer APIs from low-level kernel isolation execution:

• docker CLI converts terminal commands into REST API requests sent over /var/run/docker.sock.
• dockerd orchestrates networks, volumes, and API requests.
• containerd manages image snapshots and container lifecycles via gRPC.
• containerd-shim keeps container processes alive independently of daemon restarts.
• runc executes system calls to set up namespaces/cgroups and then replaces itself with the container process.

In the next article, we examine The Open Container Initiative (OCI): Image Specification and Runtime Specification.

Think of a container as a hotel room. You share the building (the machine) with other guests, but your room has its own door, its own bathroom, and a meter that limits how much water you can use. Nothing in the building was invented for you. The hotel just arranges existing walls and plumbing so that your room feels private.

Docker didn't invent container isolation.

A container is an ordinary program run so that it sees only its own files, its own network, and a limited share of the machine's resources, as if it had a computer to itself. Linux can do this without Docker.

The kernel is the core of the operating system: the part that controls the hardware, the memory, and the running programs on behalf of every other program. A process is one running instance of a program, and Linux gives each process a number called a process ID (PID).

By the late 2000s, the Linux kernel already had the building blocks for running an isolated process:

• Namespaces (clone(2) flags like CLONE_NEWPID, CLONE_NEWNET, and CLONE_NEWNS) to give processes their own isolated view of system trees. A namespace gives a process its own private view of one kind of system resource, such as the list of process IDs, the network interfaces, or the mounted filesystems. clone(2) is a system call, which is a request a program makes to the kernel for something it cannot do itself, such as creating a process. The CLONE_NEW... flags ask the kernel to create new namespaces for that process. The (2) is the section of the Linux manual where system calls are documented.
• Control Groups (cgroups) to cap CPU cycles, RAM, and block I/O. A cgroup is a kernel feature that sets limits on how much processor time, memory, and disk reading and writing (block I/O) a group of processes may use.
• pivot_root and chroot to swap root filesystems. Both are system calls that change what a process treats as the top-level folder /, so it cannot see files outside that folder. A root filesystem is the full directory tree a program expects to find, starting at /.

Yet almost nobody was deploying microservices in containers back then. Microservices means building one application as many small programs that talk to each other over a network.

The reason was practical ergonomics: stitching those primitives together by hand was a nightmare. Setting up an isolated environment meant calling those system calls yourself, mounting virtual /proc filesystems manually, setting up virtual ethernet pairs with raw ip link commands, and tweaking pseudo-files inside /sys/fs/cgroup/.

Some of those terms need unpacking. Mounting attaches a filesystem to a folder so its contents appear there. /proc and /sys are special folders where Linux exposes kernel information as files, and writing to some of them changes kernel settings. A virtual ethernet pair (veth) is two software network ports joined like the two ends of a cable: whatever enters one end comes out the other. ip link is a command-line tool for managing network interfaces.

Miss a single cleanup step in a bash script (a text file of shell commands that run in order), and your process leaked network interfaces into the host namespace or left root mount points exposed. The host is the real machine, or the operating system, that runs the containers. Leaking means leaving stray network devices or mounts behind on it.

Docker succeeded because it solved the distribution and developer experience problem. It took the disconnected kernel interfaces and wrapped them in a consistent runtime model. A runtime is the software that actually starts and manages containers, and distribution means getting software onto other machines.

The Raw Primitive Gap

To see why the abstraction matters, contrast what the kernel expects with what Docker presents to the user. It is like cooking from raw ingredients versus ordering a ready meal: the left side is the manual steps, and the right side is the one Docker command that does them all.

RAW LINUX KERNEL CALLS                         DOCKER RUNTIME ABSTRACTION
+---------------------------------------+     +---------------------------------------+
|  sys_clone(CLONE_NEWPID | NEWNET...)  | --> |  docker run -d --name web -p 80:80 \  |
|  /sys/fs/cgroup/memory/my_app/        |     |             -m 512m nginx             |
|  mount -t overlay ...                 |     |  (Single declarative execution)       |
+---------------------------------------+     +---------------------------------------+

In the Docker command, -d runs the container in the background, --name web names it, -p 80:80 connects port 80 on the host to port 80 in the container, -m 512m caps its memory at 512 megabytes, and nginx is the image to run. nginx is a popular web server program, and an image is the packaged software the container starts from (more on images below).

Without Docker or a container manager, running an isolated web server requires orchestrating five separate subsystems:

1. Process Isolation: Calling clone(2) or unshare(2) with half a dozen flags to detach PID, mount, IPC, and network trees. unshare(2) is a system call that detaches the calling process from namespaces it shares with others. PID means process ID numbers, and IPC (inter-process communication) means shared memory and message queues.
2. Filesystem Pivoting: Unpacking a rootfs tarball, setting up tmpfs mounts, and executing pivot_root(2) so the process can't escape into the host root. A tarball is a single archive file (.tar) that bundles many files, and tmpfs is a filesystem kept in memory instead of on disk.
3. Resource Guardrails: Writing memory limits into /sys/fs/cgroup/memory.max and writing the target process ID into cgroup.procs. In plain terms, you write a number into one file and the process's ID into another, and the kernel reads those files as instructions.
4. Network Plumbing: Giving the container a working network connection and making it reachable from outside. In plain terms, this takes five steps:
   • Create a veth pair, the two linked virtual ports described earlier.
   • Move one end into the container's network namespace, so the container owns it.
   • Attach the other end to a bridge on the host. A bridge is a software network switch that connects several virtual ports.
   • Give the container an IP address from a subnet. An IP address identifies a machine on a network, and a subnet is a block of related addresses.
   • Add an iptables rule for port forwarding. iptables is the Linux firewall and packet-rewriting tool. DNAT (destination network address translation) rewrites a packet's destination address, which is how traffic arriving at a port on the host gets sent on to the container. A port is a numbered door on an IP address that a program listens on.
5. Artifact Packaging: Figuring out how to ship dependencies and runtime binaries in a repeatable bundle. Dependencies are the other pieces of software a program needs to run, and binaries are compiled, ready-to-run program files.

Docker packaged those responsibilities into four core components. These are the four numbered sections below. They are a different grouping from the five jobs above, not a one-to-one match, so do not expect job 1 to line up with section 1.

1. The Portable Root Filesystem (OCI Image Format)

A shipping container holds goods in a standard box that any ship or truck can carry. A Docker image does the same for software: the program plus everything it needs, in one standard package. OCI (Open Container Initiative) is the published standard for that image format.

Before container images became standard, distributing software meant building RPMs, Debian packages, or shipping fat tarballs. RPM and Debian packages are the install formats used by the Red Hat and Debian families of Linux. If the host machine had a mismatched glibc version or was missing libssl.so.1.1, the deployment broke on startup. glibc is the standard C library most Linux programs depend on, and libssl.so.1.1 is a shared library file (a file of code that many programs load) used for encryption. If the machine has a different version than the program expects, the program fails.

Docker paired the root filesystem with a JSON manifest, a small text file that describes what the image contains and how to run it. The image contains:

• The exact root directory tree (rootfs) required by the app.
• Every shared library, binary, and configuration file.
• Metadata describing entrypoints, environment defaults, and exposed ports. The entrypoint is the command that starts when the container runs, and environment variables are named settings passed to the program.

Because the process runs against its own bundled rootfs rather than the host's /usr/lib (the folder where Linux keeps shared libraries for installed programs), it runs with identical behavior on a local laptop or an AWS instance running a completely different Linux distribution. A distribution is a packaged version of Linux, such as Debian or Fedora, and an AWS instance is a virtual server rented from Amazon Web Services.

2. Copy-on-Write Layering via OverlayFS

Shipping a full root filesystem on every minor code change would slow deployment and waste disk space.

Imagine a printed page covered by clear plastic sheets. You write on the top sheet and never touch the page underneath. Layers work like those sheets. Copy-on-write means a file is copied only at the moment someone first changes it. OverlayFS is the Linux filesystem that stacks layers so they appear as one folder.

Docker solved this with layered storage drivers (primarily OverlayFS). When building an image, each instruction produces an immutable layer identified by a SHA-256 digest. Immutable means never changed after creation. A SHA-256 digest (a hash) is a fixed-length fingerprint computed from content, so identical content always gets the same fingerprint. If five different services build on debian:bookworm-slim (the name and tag of a small Debian base image), they all share the exact same base layer on disk and in the page cache, which is the memory the kernel uses to keep recently read file data:

+---------------------------------------------------------------+
| Container Writable Layer (Read/Write Delta)                    |
+---------------------------------------------------------------+
| Layer 3: Application Binary (12 MB)                           |
+---------------------------------------------------------------+
| Layer 2: Go Runtime / Libraries (110 MB)                      |
+---------------------------------------------------------------+
| Layer 1: Debian Base OS (55 MB) [Shared across all containers]|
+---------------------------------------------------------------+

The sizes in this diagram are illustrative example values, not measurements. The example assumes the app was written in Go, a programming language, so layer 2 holds the Go runtime and libraries. The top box is the container's own writable layer, where its changes are stored.

The container only writes changes to its thin top layer. The heavy base remains read-only and shared. If a program edits a file that lives in a lower layer, that file is first copied up into the top layer and edited there, and the lower layers stay unchanged.

3. Automated Bridge Networking and Embedded DNS

Each container is like a separate house that needs a street, an address, and a way for mail to reach it. Docker lays the street (a bridge), assigns the addresses, and forwards the mail (ports).

Configuring Linux network namespaces by hand is tedious and error-prone. Here, <container_pid> stands for the process ID of the container's main process, and br0 is a bridge you created earlier:

# Manual Linux Networking setup (WITHOUT Docker):
# 1. Create a linked pair of virtual ports, veth0 and veth1.
ip link add veth0 type veth peer name veth1
# 2. Move one end (veth1) into the container's network namespace.
ip link set veth1 netns <container_pid>
# 3. Give that end an IP address. The /24 means the first 24 bits
#    identify the network (CIDR notation for the subnet size).
ip addr add 192.168.1.2/24 dev veth1
# 4. Plug the other end (veth0) into the bridge br0.
ip link set veth0 master br0
# 5. Forward TCP traffic arriving on port 80 to the container.
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80

With Docker, -p 8080:80 triggers all of this automatically. It means connections to port 8080 on the host go to port 80 inside the container. The daemon (a program that runs continuously in the background; Docker's is called dockerd) manages virtual bridge devices (docker0), allocates private IPs from an internal subnet, sets up kernel forwarding rules, and runs an internal DNS resolver at 127.0.0.11 so containers talk to each other by container name instead of volatile IP addresses. DNS translates names into IP addresses. The 127.x.x.x addresses refer to the local machine, so 127.0.0.11 is reachable only from inside the container. Volatile means the address can change each time a container restarts.

4. Content-Addressable Distribution (Registry Protocol)

A registry is like a library of images: you push to upload one and pull to download one. Content-addressable means each item is looked up by a fingerprint of its content, not by a name someone chose.

Docker standardized how images get pushed, pulled, and verified through the Docker Registry HTTP API V2. HTTP is the standard protocol web browsers use, and this API is how Docker talks to a registry over it.

Because every layer is identified by its SHA-256 hash, pushing an update transfers only the modified layer delta, meaning only the part that changed. If your base layers didn't change, the registry skips them entirely. Before uploading each layer, Docker checks whether the registry already has one with the same fingerprint, and skips it if so.

What Comes Next

Understanding these boundaries changes how you debug container issues. When an application gets killed with exit code 137, that's not a mystery inside Docker. An exit code is the number a program returns when it stops, and 137 means the process was killed by signal 9 (SIGKILL), because shells report 128 plus the signal number. One common cause is the kernel's cgroup memory controller enforcing a memory limit, but any SIGKILL produces 137, so treat it as a hint and check the container's memory limit and logs. When a port is unreachable, the culprit is usually an iptables rule or a missing route on the bridge. A route is a rule telling the kernel where to send packets for a given address.

In Part 2, we trace the execution path from the Docker CLI command down through dockerd, containerd, and runc (the three programs in Docker's execution chain, each explained there) to see what happens the moment you press enter.