🐳 Docker Architecture and Components

The Docker Platform

Docker is a platform for building, packaging, and running applications in containers. It's practically synonymous with containerization because it made containers usable for everyday development, not just for kernel specialists. In the last lesson you learned what containers are; now you'll learn how Docker actually runs them.

The platform is more than one program. At a high level it includes the Docker Engine (the core runtime), the CLI client you type commands into, Docker Compose for multi-container apps, Docker Desktop (the GUI bundle for Windows/macOS), and Docker Hub (the default registry).

Client-Server Architecture

Docker uses a client-server architecture. The Docker client (the docker command) talks to the Docker daemon (dockerd) over a REST API. The daemon does the real work — building images, running containers, managing networks and volumes. Because the API is network-capable, the client can even control a daemon on a different machine.

📺 Remote and TV: The client is the remote control — you press buttons (issue commands). The daemon is the TV's internal circuitry — it does the actual work of changing channels and adjusting volume. Pressing the remote doesn't do anything by itself; it just sends a signal.

The core components

• Docker Client — the CLI/API you interact with
• Docker Daemon (dockerd) — the background service that manages all Docker objects
• containerd — a runtime that manages the container lifecycle
• runc — the low-level runtime that creates the container by talking to the kernel
• Registry — stores and distributes images

Common client commands

# Run a container from the nginx image
docker run nginx

# List running containers
docker ps

# Build an image from a Dockerfile in the current directory
docker build -t myapp .

# Pull an image from a registry
docker pull ubuntu:22.04

# Push an image to a registry
docker push myusername/myapp:1.0

containerd and runc

Docker didn't stay one monolithic program. Its core runtime was split out into reusable, standardized pieces — containerd and runc — which are now governed independently and used by other systems (Kubernetes talks to containerd directly). Understanding the split explains what each layer is responsible for.

containerd

A daemon that manages the complete container lifecycle on a host: pulling and storing images, and starting, supervising, and stopping containers. If dockerd is the head chef coordinating the kitchen, containerd is the station chef who actually runs the cooking processes.

runc

A lightweight runtime implementing the Open Container Initiative (OCI) spec. It does the low-level work of creating a container: setting up Linux namespaces and cgroups, configuring capabilities and the filesystem, then executing the container process. runc is the cook preparing an individual dish from a precise recipe.

containerd-shim

A tiny process that sits between containerd and the running container. It lets containers keep running even if containerd restarts, reports the container's exit status back, and keeps the I/O streams open. Think of it as the kitchen expediter making sure finished plates are delivered even when the chef is slammed.

Images, Layers & Copy-on-Write

Docker images are read-only templates built from stacked filesystem layers. Each instruction in a Dockerfile produces one layer capturing just the changes from the step before it.

# Layer 1: base image
FROM ubuntu:22.04

# Layer 2: install Node.js
RUN apt-get update && apt-get install -y nodejs npm

# Layer 3: set the working directory
WORKDIR /app

# Layer 4: copy application code
COPY . .

# Layer 5: install dependencies
RUN npm ci

# Layer 6: declare the port
EXPOSE 3000

# Layer 7: startup command
CMD ["npm", "start"]

Union filesystem

Docker uses a union filesystem to stack these read-only layers into one coherent view. It's like transparent overlays in an image editor: each sheet sits on the ones below it, and the topmost version of a file wins.

Copy-on-write

When a container runs, Docker adds a thin writable layer on top of the read-only image layers. Changes use a copy-on-write mechanism:

1. Reading an unmodified file reads straight from the lower image layers.
2. Modifying a file first copies it up into the writable layer, then edits the copy.
3. All later reads see the modified copy from the writable layer.

📄 The photocopy analogy: Instead of writing on the original document, you make a photocopy and mark that up. Your notes are all yours; the pristine original stays available for everyone else — which is exactly why many containers can safely share one image.

Storage: Volumes, Binds, tmpfs

Because the writable layer is ephemeral, Docker offers three ways to handle data that needs to outlive — or bypass — the container.

Volumes (preferred)

Created and managed by Docker, stored in a Docker-controlled area of the host. Volumes persist independently of any container, can be shared between containers, and are easy to back up.

# Create a named volume
docker volume create my-data

# Mount it into a container
docker run -v my-data:/app/data nginx

# List and inspect volumes
docker volume ls
docker volume inspect my-data

Bind mounts

Map a specific host directory straight into the container. Great for development — edit code on the host and see it live in the container — but tied to the host's exact directory layout.

# Map a host path into the container
docker run -v /host/path:/container/path nginx

tmpfs mounts

Store data in the host's RAM only, never on disk. Ideal for fast scratch space or sensitive data that must not persist.

# Mount an in-memory filesystem
docker run --tmpfs /app/temp nginx

📓 Three notebooks: A volume is a dedicated journal that lives on your bookshelf. A bind mount is a sticky note stuck onto a surface you already have. A tmpfs mount is an erasable whiteboard that wipes clean the moment the power goes off.

Networking

Docker gives containers a networking system so they can talk to each other and to the outside world. It ships several network drivers for different situations.

Container-to-container communication

On a user-defined bridge network, containers reach each other by name — Docker runs an embedded DNS server that resolves container names to their current IP addresses. No hard-coded IPs required.

# Create a network and run a web server on it
docker network create my-network
docker run -d --name web --network my-network nginx

# Another container reaches it simply as "web"
docker run --network my-network alpine wget -qO- http://web

☎️ The telephone exchange: Different drivers are like different kinds of phone lines, but they all connect callers (containers) using rules and a directory (DNS) so nobody needs to memorize raw numbers (IPs).

Registries

A registry stores and distributes images. Docker Hub is the default public registry; teams also run private registries or use cloud ones like Amazon ECR, Google Artifact Registry, and Azure Container Registry.

# Pull an image from Docker Hub
docker pull nginx:latest

# Tag a local image for a registry namespace
docker tag my-app:1.0 username/my-app:1.0

# Authenticate, then push
docker login
docker push username/my-app:1.0

# Pull from a private registry by hostname
docker pull registry.example.com/my-app:1.0

A registry works like a package-distribution center: developers deliver packaged apps (images), the center shelves them in organized repositories, and delivers them to users on request.

Docker Compose

Real apps rarely run in a single container — you might have a web server, an app, and a database that all need to start together and talk to each other. Docker Compose describes that whole stack in one YAML file and brings it up with one command.

# compose.yaml
services:
  # Reverse-proxy / static web server
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./website:/usr/share/nginx/html
    depends_on:
      - app

  # Application server built from a local Dockerfile
  app:
    build: ./app
    environment:
      - NODE_ENV=production
      - DB_HOST=db
    depends_on:
      - db

  # Database with a named volume for persistence
  db:
    image: postgres:16
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=change_me
      - POSTGRES_USER=myuser
      - POSTGRES_DB=myapp

volumes:
  postgres_data:

# Start the whole stack in the background
docker compose up -d

# View logs, stop everything, or scale a service
docker compose logs -f
docker compose down
docker compose up -d --scale app=3

Compose is a blueprint plus a construction manager: the YAML is the blueprint specifying how everything connects, and the up command is the manager that builds and wires it all together to plan.

Hands-on Exercise

Summary & Quiz

📚 Further Reading

• Docker — Architecture overview
• Docker — Storage documentation
• Docker Compose documentation

🚀 What's Next?

Theory in place, it's time to get Docker actually running on your machine. Next we cover installation and configuration across Windows, macOS, and Linux — plus resources, contexts, and security settings.