The Docker Architecture

"Docker" is not one program. The docker you type is a thin CLI that sends HTTP requests to a long-running daemon called dockerd; the daemon hands the real container work to containerd, which in turn spawns runc to set up the namespaces and cgroups from topic 03 and start the process. Four components in a chain, each with one job.

Understanding the client → daemon → containerd → runc path explains three things at once: why Docker needs a running background service, why it usually needs root, and what is left if you remove Docker itself. None of those make sense if you think of docker as the thing that runs containers — because it does not.

docker        # the CLI you type — stateless, just sends HTTP
  └─▶ dockerd       # the daemon — owns images, networks, volumes
        └─▶ containerd    # manages image + container lifecycle
              └─▶ runc         # sets up namespaces/cgroups, execs the process, exits
                    └─▶ containerd-shim   # the lingering parent of your container

Read that chain top to bottom: each layer delegates downward and does less low-level work than the one below it. The CLI knows nothing about kernels; runc knows nothing about HTTP. The error messages you will hit map directly onto this chain, which is the practical payoff of learning it.

Client and Daemon

The docker CLI is stateless. It holds no images, runs no containers, and remembers nothing between invocations — it serializes your command into an HTTP request and sends it to the daemon over a socket, by default the Unix socket at /var/run/docker.sock. The daemon, dockerd, owns everything: the image store, the running containers, the networks, and the volumes. Stop dockerd and every container stops with it, because the daemon is the process actually supervising them.

This client-server split is also a security fact. Anyone who can reach the daemon socket can tell the daemon to do anything — including run a container that mounts the host's root filesystem — so access to /var/run/docker.sock is effectively root on the host. That single sentence explains most of the security advice in this chapter and Chapter 10.

The Daemon Delegates

dockerd handles the high-level API — building images, creating networks, managing volumes, exposing the REST endpoints the CLI calls — but it does not manage the container lifecycle itself. It delegates that to containerd, a separate daemon that pulls and stores images and supervises running containers at a lower level. The division is deliberate: dockerd is the Docker-specific front end, and containerd is a general-purpose container manager that has a life of its own beyond Docker.

runc and the OCI Runtime

When a container actually needs to start, containerd calls runc, the reference implementation of the OCI runtime specification. runc does the kernel work topic 03 described: it creates the namespaces, configures the cgroups, sets up the union mount, and exec's the container's process. Then it exits. It is a short-lived tool that builds the fence and walks away, not a supervisor that stays running.

What remains as the container's parent is a lightweight containerd-shim process. The shim keeps the container's stdio open and reports the exit code back to containerd, which is why your containers survive a restart of dockerd itself — the shims, not the daemon, are holding them. One shim per container is the price of decoupling the daemon's lifecycle from the containers it started.

Why It's Layered This Way

The split lets each component evolve and be reused independently, and the clearest payoff is Kubernetes. Kubernetes talks to containerd directly through the Container Runtime Interface and skips dockerd entirely — it never needed the Docker-specific front end. That is exactly what the "Kubernetes deprecated Docker" headlines of 2020 meant: Kubernetes dropped the dockerd shim layer it used to talk through, not Docker images.

The images Docker builds are OCI images, and OCI images run unchanged on containerd, on Podman, and under Kubernetes. Nothing about your docker build output stopped working when Kubernetes dropped the daemon. Conflating "Kubernetes dropped dockerd" with "Docker images stopped working" caused a wave of needless panic — the artifact and the daemon are independent.

Rootful by Default, and the Socket

By default dockerd runs as root, so every docker command you issue executes with root authority on the host. That is convenient and dangerous in equal measure: a container can be told to bind-mount / from the host and edit any file on the machine. Chapter 10 covers rootless mode, which runs the daemon as an unprivileged user, but the default install is rootful.

Two consequences follow directly. Mounting /var/run/docker.sock into a container hands that container root-equivalent control of the host's Docker — a routine and dangerous footgun. And adding a user to the docker group, which grants access to that socket, is equivalent to giving them root; do it as deliberately as you would edit the sudoers file.