The `docker` command-line tool does not itself create containers. Describe the client/daemon architecture behind it and what actually happens when you run a docker command on a Linux host.

## Two programs, not one People say "Docker" as if it were a single binary. On Linux it is at least two: the **client** (`docker`) and the **daemon** (`dockerd`). The client holds essentially no logic about containers. It parses your flags, turns them into an HTTP request against the **Docker Engine API**, sends it, and renders the response. The transport is chosen by `DOCKER_HOST` (or the active `docker context`): - default on Linux: the Unix socket `unix:///var/run/docker.sock` - `ssh://user@host` — tunnel to a remote daemon - `tcp://host:2376` — TCP, which should always be mutual-TLS So `docker ps` is roughly `GET /containers/json`, `docker run` is a `POST /containers/create` followed by `POST /containers/{id}/start` plus a stream attach, and `docker build` uploads the build context and streams back progress. ## What the daemon owns `dockerd` is a long-running privileged process (root, unless you deliberately run rootless mode). It owns: - the local **image store** and pulls/pushes to registries - **container** records, names, labels, restart policies, logging drivers - **networks** (bridge creation, iptables rules, DNS for user-defined networks) and **volumes** - the **build** front end, delegating to BuildKit - the API itself, including its version negotiation with older clients What it does *not* do is create namespaces and cgroups itself. It hands that down to containerd, which invokes a shim and `runc`. The daemon is the control plane, not the executor. ## Consequences you are expected to draw **Your shell is not the parent.** `docker run -it alpine sh` looks like a subprocess, but the container process was created several layers below the daemon; the CLI merely attached stdin/stdout/stderr to the API stream. Detaching (`Ctrl-P Ctrl-Q`) or losing the terminal does not kill the container. Conversely `docker stop` sends `SIGTERM` to the container's PID 1 via the daemon, not via your shell's job control. **Remote control is free.** The same CLI drives a daemon on another machine by switching context. This is also why CI systems can build "locally" against a remote engine. **Socket access equals root.** Anyone who can write to `/var/run/docker.sock` can ask the daemon — which runs as root — to start a container with `--privileged` and `-v /:/host`, and thereby read or modify anything on the host. Adding a user to the `docker` group is therefore a root grant, and mounting the socket into a container hands that container the host. (Rootless mode and socket-proxy filtering are the usual mitigations.) **Failure modes are separable.** If `dockerd` crashes or is being upgraded, the CLI reports `Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?` — but running containers may well still be serving traffic, because they are supervised by per-container shim processes rather than by the daemon itself. **API versioning is real.** The client negotiates an API version with the daemon; a very new client against an old daemon downgrades, and a client asking for features the daemon lacks gets a clear version error. `docker version` prints both sides, which is the first thing to check when a flag "does not exist" on one machine. ## Where Docker Desktop differs On macOS and Windows there is no Linux kernel to host containers, so Docker Desktop runs a Linux VM; `dockerd` lives inside that VM and the socket you talk to is a proxy into it. This is why bind-mount performance and file-permission behaviour differ from Linux, and why "localhost" semantics need care. The client/daemon split is the same — the daemon is simply one virtualization boundary away. ## Quick self-check You can bypass the CLI entirely and prove the model: ``` curl --unix-socket /var/run/docker.sock http://localhost/v1.45/containers/json ``` If that returns JSON, you have just done what `docker ps` does.