Deep Dive into Docker Architecture

Introduction

Docker has become a fundamental tool in modern software development, enabling teams to package applications and dependencies into portable, reproducible containers. But beyond the docker run commands and image pulls lies a rich architecture that powers Docker’s capabilities.

In this article, we’ll walk through:

• Docker’s high-level architecture (client, daemon, registry)
• The runtime stack (containerd, runc, shim)
• Docker objects and subsystems (images, containers, storage, networking)
• A detailed flow of what happens when you run a container
• Strengths, trade-offs, and design considerations

---

Docker’s High-Level Architecture

Docker is built on a client–server model:

• The Docker Client (often CLI) — the interface through which users issue commands.
• The Docker Daemon (also called Engine or dockerd) — the background service that listens for requests and performs container operations.
• Docker Registry — a store for container images (public or private).

The client and daemon communicate via a REST API (over a Unix socket or TCP). This model allows local or remote interactions.

Docker Client ←→ Docker Daemon / Engine
│ │
│ ├── uses runtime layer (containerd / runc)
│ ├── manages images, containers, networks, volumes
│ └── interfaces with host OS / kernel
│
└── push / pull → Docker Registry

This architecture is also explained in the GeeksforGeeks article. :contentReference[oaicite:0]{index=0}

---

Core Components & Their Roles

Docker Client

• Receives user commands (e.g. docker run, docker build).
• Converts commands into REST API calls to the Docker daemon.
• Can talk to one or more daemons (local or remote).

Docker Daemon (Engine / dockerd)

• Listens for API requests from clients.
• Manages Docker objects: images, containers, networks, volumes, etc. :contentReference[oaicite:1]{index=1}
• Delegates tasks to lower-level runtime components.
• In clustered modes (e.g. Swarm), interacts with other daemons across nodes.

containerd

• A runtime daemon often used by Docker under the hood.
• Handles image transfer, storage, and container lifecycle tasks. :contentReference[oaicite:2]{index=2}
• Acts as a bridge between Docker’s high-level logic and the low-level runtime (runc).

runc

• An OCI-compliant low-level runtime that actually spawns containers.
• Uses Linux kernel features (namespaces, cgroups, mount, etc.) to isolate container processes. :contentReference[oaicite:3]{index=3}

containerd-shim

• After container creation, the shim becomes the parent of the container process.
• It handles I/O, signals, logs, and ensures the container remains alive even if the main daemon restarts.

Docker Registry

• A storage & distribution system for container images.
• Docker Hub is a popular public registry, but private registries (Harbor, ECR, GCR, etc.) are often used. :contentReference[oaicite:4]{index=4}
• The daemon or runtime pulls images from the registry, or pushes newly built images to it.

---

Docker Objects & Supporting Subsystems

Images & Layers

• A Docker image is a read-only template made up of multiple layers.
• Each instruction in a Dockerfile (e.g. RUN, COPY) adds or modifies layers.
• Layering enables caching, efficient storage, and reuse across images.

Containers

• A running instance of an image with isolated environment.
• Uses kernel namespaces (PID, network, mount, etc.) for isolation and cgroups for resource constraints.
• Containers share the host kernel (i.e. they are not full VMs).

Storage & Volumes

• Containers have ephemeral filesystems; changes vanish when containers stop.

• Persistent data is managed via:

  • Volumes — Docker-managed storage outside container layers
  • Bind mounts — mounting host directories inside containers
  • tmpfs mounts — in-memory storage (non-persistent)
  • Storage drivers — overlay2, aufs, btrfs, etc., manage how layers are stored/merged on the host filesystem :contentReference[oaicite:5]{index=5}

Networking

Docker supports multiple network modes and drivers:

• bridge (default on single host)
• host (shares host’s network namespace)
• overlay (for multi-host networking)
• none (no network)
• macvlan (container appears as a device on the network)

Docker networking also manages DNS, port mapping (-p), and custom plugin support.

---

Detailed Flow: What Happens During docker run

Let’s follow the steps when you run:

bash
docker run -d -p 80:80 nginx