Topic 0.3
The Docker Architecture
In one line
Client, Daemon, Registry — the three pieces that work together every time you type a docker command, and the client-server model that explains a surprising amount of 'weird' Docker behavior.
Think of it like this
Ordering food through a delivery app. YOU (the Docker CLI/client) place an order. The RESTAURANT KITCHEN (the Docker daemon, dockerd) actually cooks the food — pulls ingredients, prepares the dish, plates it. The SUPPLIER WAREHOUSE (a registry like Docker Hub) is where the kitchen sources ingredients (images) it doesn't already have on hand.
Key ideas
- 01
Docker Client: the
dockercommand you type. It doesn't do the actual work — it sends your request (as an API call) to the Docker daemon. - 02
Docker Daemon (dockerd): the background process that does the REAL work — building images, running containers, managing networks and volumes. It listens for API requests from the client.
- 03
This is a client-server architecture, even on your own single laptop: the CLI and the daemon are two separate processes talking over an API (usually a local Unix socket, but it can be a remote TCP connection too — meaning your local
dockercommand can control containers running on a totally different machine). - 04
Docker Registry: a server that stores and distributes images (Docker Hub is the default public one; companies also run PRIVATE registries for their own images).
docker pulldownloads an image FROM a registry;docker pushuploads one TO a registry. - 05
The full request path for
docker run nginx: Client sends 'run nginx' to the Daemon → Daemon checks if it has thenginximage locally → if not, Daemon pulls it from the default registry (Docker Hub) → Daemon creates and starts a container from that image. - 06
Why this matters practically: this is why
docker runcan be slow the FIRST time (pulling the image over the network) but instant afterward (the image is now cached locally), and why you can rundockercommands against a remote server just by pointing your client at a different daemon.
In your stack
- →
In a typical company setup, developers' laptops run the Docker client pointed at their OWN local daemon for development, while the CI/CD pipeline builds a Spring Boot app's image and PUSHES it to a private registry (e.g. AWS ECR, or a self-hosted Nexus/Artifactory), and production servers PULL that exact same image to run it — nobody rebuilds the image on production, they just pull the already-tested artifact.
Code & diagrams
Trace this exact path in your head every time you run a docker command.
Explain it without notes
Why is docker run nginx slow the very first time you ever run it, but fast every time after?
Your Docker client can control containers on a DIFFERENT machine than the one you're typing on — explain how that's architecturally possible.
Practice
Run docker info on your own machine (if Docker is installed) and find the section describing the daemon — note anything about the number of containers/images currently on your system.
Predict: if you delete an image with docker rmi and then run a container from that same image name again, what will happen? Then verify.
Trade-offs
- ↔
The client-server split adds a small conceptual overhead for beginners (why isn't
dockerjust one program?), but it's exactly what enables remote Docker control, Docker-in-CI, and tools like Docker Desktop's GUI to all drive the SAME daemon through the SAME API.
Done when you can
I can name the three architecture pieces (Client, Daemon, Registry) and what each one does.
I can trace the exact path of a
docker runcommand from typing it to a container starting.