Discuss docker architecture.
Docker uses a client-server architecture. The Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers. The Docker client and daemon can run on the same system, or you can connect a Docker client to a remote Docker daemon. The Docker client and daemon communicate using a REST API, over UNIX sockets or a network interface. Another Docker client is Docker Compose, that lets you work with applications consisting of a set of containers. Here are the three primary components that make the system work:
- 1
It is the command-line interface (CLI) or a desktop application. When you type docker build or docker pull, the client sends these commands to the Docker Daemon using a REST API.
- 2
Role: It acts as the primary interface. It doesn't actually run containers; it just sends instructions (API calls) to the Docker Daemon.
- 3
Flexibility: A single client can connect to multiple daemons (even remote ones on AWS).
- 1
Docker Daemon (dockerd): This is the 'brain' of Docker. It listens for API requests from the client and manages Docker objects like images, containers, networks, and volumes.
- 2
containerd & runc: Lower-level runtimes. The daemon delegates the actual 'starting' of a container to containerd, which uses runc (an OCI-compliant tool) to interact with the Linux kernel.
- 3
Images: Read-only templates used to create containers. Think of an image as a 'recipe' or a snapshot of a filesystem.
- 4
Containers: The runnable instances of images. If an image is a class, a container is an object.
- 1
Role: A storage system for images.
- 2
Types: Docker Hub (Public) or Amazon ECR (Private).
- 3
Workflow: When you run docker pull, the Host checks if the image exists locally; if not, it fetches it from the Registry.
- 4
Docker Hub is the default public registry where anyone can find or share images.
- 5
When you execute a docker pull command, the host fetches the requested image from the registry and stores it locally.
Scenario Questions
0-2 years experience
- 1If you need to run a simple web app in a Docker container on your laptop, which Docker components are involved from the moment you run `docker run` to the container starting?
- 2What happens on your machine when you execute `docker build` with a Dockerfile that has multiple `FROM` statements?
2-5 years experience
- 1Your CI pipeline is failing when building an image that uses a multi‑stage build; the logs show the daemon can't find a layer. How would you troubleshoot this using your knowledge of Docker's architecture?
- 2You notice that containers started from the same image are consuming more memory than expected. Which parts of Docker's architecture would you examine to identify the cause?
5-8 years experience
- 1We need to design a high‑throughput microservice platform that runs thousands of containers per node. How would you leverage Docker's architecture (daemon, container runtime, storage drivers) to ensure isolation and performance at scale?
- 2During a rolling upgrade, some services experience brief network interruptions. Explain how Docker's networking stack interacts with the daemon and what architectural changes could mitigate this.
8+ years experience
- 1Our organization is moving from a monolithic VM‑based deployment to a container‑first strategy across multiple data centers. What architectural considerations around Docker's daemon placement, storage driver selection, and image distribution would you advise to minimize operational risk?
- 2We plan to build an internal platform that abstracts Docker for multiple teams, providing custom security policies and resource quotas. How would you design the platform's interaction with Docker's architecture to enforce these policies while keeping upgrade paths smooth?
Follow-up Questions
- Can you walk me through the steps the daemon takes when pulling an image?
- How does the choice of storage driver impact container startup time and disk usage?
- What are the trade‑offs between using overlay2 versus devicemapper?