Anatomy of the Engine

What Happens When You Type docker run

So far "Docker" has meant one thing: the docker command you type. Under the hood, though, it's not one program - it's a small chain of cooperating background programs called daemons (a daemon is just a process that runs continuously in the background, with no terminal attached, waiting to do work on request - the same idea as a Windows "service"). Understanding this chain explains a lot of behavior you'll otherwise find mysterious, like why containers keep running after you close your terminal.

docker the command you type is just a client - it doesn't do any of the real work itself. It sends a request over the network (technically a local socket file, explained below) and something else acts on it:

docker CLI ──REST /var/run/docker.sock──▶ dockerd ──▶ containerd ──▶ runc
 (client)                                 (API,      (container     (creates the
                                          images,     lifecycle)     namespaces/
                                          networks)                  cgroups, exits)

• dockerd - the Docker daemon: API server, image builds, networks, volumes
• containerd - manages container lifecycle; also used directly by Kubernetes
• runc - the low-level program (an OCI runtime - OCI is the industry-wide Open Container Initiative standard that all these tools agree to follow) that actually sets up the namespaces and cgroups from the previous module and starts the isolated process, then exits immediately. This is the detail that surprises most newcomers: your container is NOT running "inside" some wrapper program the whole time - after runc hands off, it's just a normal process, visible in the host's own ps output like any other program.

Note: This layering is why the OCI standards matter: because dockerd, containerd and runc all speak the same standard image/runtime format, images and runtimes are interchangeable. The image you build with Docker runs unchanged on Kubernetes, Podman, or any other OCI-compliant runtime.

Danger: The client talks to dockerd over /var/run/docker.sock, and dockerd runs as root. Access to that socket = root on the machine. This one fact drives half of Docker security practice.