Docker Architecture

Docker Architecture

Docker uses a client-server design. The docker CLI sends API requests to the selected daemon. The daemon coordinates image builds and pulls, container lifecycle, networks, volumes, and the lower-level runtime that launches isolated processes.

Core ideas

• The client can talk to a local or remote daemon through a Docker context.
• A registry stores repositories of image manifests and layer blobs.
• An image reference can use a mutable tag or an immutable digest.
• A container combines image layers, a writable layer, process configuration, mounts, and network endpoints.

How it works

For docker run, the daemon resolves the image, pulls missing content from the registry, creates writable state and networking, applies limits, and starts the configured entrypoint. The client can attach to streams or return immediately in detached mode. Container state remains owned by the daemon endpoint, not the CLI machine.

Command or configuration example

# The context decides which daemon receives these requests
docker context show
docker image pull alpine:3.20
docker container create --name architecture-demo alpine:3.20 sleep 60
docker container start architecture-demo
docker container inspect architecture-demo
docker container rm -f architecture-demo

Run examples first in a disposable environment. Replace image names, versions, credentials, ports, paths, and resource values with reviewed settings appropriate to your system.

Production guidance

• Use fully qualified image names for production registry clarity.
• Understand that deleting a container does not automatically delete its image or named volumes.
• Restrict access to the daemon: control of its API commonly permits control of the host.

The chapter quiz follows this lesson and checks the concepts as well as the operational tradeoffs.