Skip to content

Lesson 1.3: Docker Architecture

Now that Docker is installed and you've run your first container, it's time to understand what's happening under the hood. Docker's architecture is a client-server model with several key components that work together to build, run, and manage containers. By the end of this lesson, you'll have a clear mental model of how Docker works.


Learning Objectives

TIP

By the end of this lesson, you will be able to:

  • Describe the main components of Docker: client, daemon, and registries.
  • Explain the relationship between images, containers, and layers.
  • Understand the basic workflow of a Docker command.
  • Use Docker commands to inspect images, containers, and system information.

1. Docker Components

Docker uses a client-server architecture. The three main components are:

  • Docker Client (docker CLI)
  • Docker Daemon (dockerd)
  • Docker Registries (like Docker Hub)

1.1. Docker Client

The Docker client is the primary way users interact with Docker. When you type commands like docker run, docker build, or docker pull, you're using the Docker client. The client communicates with the Docker daemon via a REST API, over Unix sockets or a network interface.

  • The client can run on the same host as the daemon or connect to a remote daemon.
  • Multiple clients can talk to the same daemon.

1.2. Docker Daemon (dockerd)

The Docker daemon runs on the host machine and is responsible for all container-related operations:

  • Listening for Docker API requests.
  • Managing Docker objects: images, containers, networks, volumes.
  • Building images.
  • Running and stopping containers.
  • Pulling and pushing images to registries.

The daemon constantly manages container lifecycles and system resources.

1.3. Docker Registries

A Docker registry stores Docker images. The default public registry is Docker Hub, but you can also run private registries (like Docker Trusted Registry, or a simple registry container).

  • When you run docker pull ubuntu, the client asks the daemon to fetch the image from a registry (by default, Docker Hub).
  • When you run docker push, the daemon uploads your local image to a registry.
  • Images can have tags (e.g., ubuntu:22.04) to differentiate versions.

Conceptual diagram:

+----------------+        REST API        +----------------+      +----------------+
| Docker Client  | ---------------------> | Docker Daemon  | ---> |   Registry     |
| (docker CLI)   |                        |   (dockerd)    | <--- | (Docker Hub)   |
+----------------+                        +----------------+      +----------------+
                                               |
                                               v
                                       +----------------+
                                       |  Containers    |
                                       |  Images        |
                                       |  Volumes, etc. |
                                       +----------------+

2. Images and Containers

Two of the most fundamental concepts in Docker are images and containers.

2.1. Images

A Docker image is a read-only template with instructions for creating a container. It contains:

  • A cut-down operating system (e.g., Ubuntu, Alpine).
  • Application code.
  • Dependencies (libraries, binaries).
  • Environment variables, configuration files.
  • Metadata (exposed ports, default command, etc.).

Images are built in layers. Each instruction in a Dockerfile (like RUN, COPY, ADD) creates a new layer. Layers are cached and reusable across images, saving disk space and speeding up builds.

INFO

Think of an image as a class in object-oriented programming: it's a blueprint.

2.2. Containers

A container is a runnable instance of an image. When you start a container from an image, Docker adds a thin writable layer (the container layer) on top of the image's read-only layers. All changes made inside the container (creating files, modifying configuration) are written to this writable layer.

  • Containers can be started, stopped, moved, and deleted.
  • When a container is deleted, its writable layer is also deleted unless you've used volumes to persist data.
  • Multiple containers can be started from the same image, each with its own isolated writable layer.

INFO

Analogy: An image is like a DVD (read-only master copy), and a container is like a VHS tape you record from that DVD – you can play it, record over it, but the DVD stays unchanged.

2.3. Image Layers in Practice

You can see the layers of an image using:

bash
docker history <image>

For example, docker history ubuntu shows the layers that make up the Ubuntu image. Each layer has a size and the command that created it.


3. Other Docker Objects

Docker manages several other objects you'll encounter:

  • Networks: Provide communication between containers or with the outside world. Types include bridge, host, overlay, etc.
  • Volumes: Persistent data storage independent of container lifecycle.
  • Plugins: Extend Docker's functionality (e.g., volume drivers, network plugins).

We'll cover these in later lessons.


4. Basic Workflow of a Docker Command

Let's trace what happens when you run docker run hello-world:

  1. You type docker run hello-world in your terminal (Docker client).
  2. The client sends an API request to the Docker daemon (via the socket).
  3. The daemon checks if the hello-world image exists locally. If not, it contacts the configured registry (Docker Hub) and requests the image.
  4. The registry sends the image layers to the daemon, which stores them locally.
  5. The daemon creates a new container from the image, setting up its filesystem, network, and process isolation.
  6. The container runs its default command (the hello-world program), which prints a message to stdout.
  7. The daemon captures the output and sends it back to the client.
  8. The client displays the output in your terminal.
  9. The container exits, but remains on disk (stopped) unless you remove it.

TIP

This entire process happens in seconds!


5. Hands-On Tasks

Now let's explore the architecture using commands.

Task 1: Inspect the Docker Daemon

Run:

bash
docker info

Look for:

  • Server Version: The daemon version.
  • Storage Driver: How images and containers are stored (e.g., overlay2).
  • Images: Number of images you have.
  • Containers: Number of containers (running, paused, stopped).
  • Docker Root Dir: Where Docker stores data on your host.

Task 2: Explore an Image's Layers

Pull the Ubuntu image if you haven't already:

bash
docker pull ubuntu:latest

Then inspect its history:

bash
docker history ubuntu

You'll see a list of layers with their creation commands and sizes. Note the <missing> lines—these are intermediate layers from the build process, not actually missing but representing build steps.

Task 3: Inspect an Image and a Container

  • Inspect the Ubuntu image metadata:
bash
docker image inspect ubuntu

This returns a JSON with details like architecture, OS, environment variables, and layers.

  • Run a simple container interactively:
bash
docker run -it --name myubuntu ubuntu bash

Inside the container, create a file:

bash
echo "Hello from container" > /tmp/test.txt
exit
  • Inspect the container (even though it's stopped):
bash
docker container inspect myubuntu

Look at the "State" section to see exit code, timestamps, and "GraphDriver" for layer information.

Task 4: Compare Image and Container Layers

List all images and containers to see sizes:

bash
docker images
docker ps -a

Notice that the image size is fixed, but the container itself doesn't add much size (its writable layer is small).

Task 5: Check Disk Usage

Run:

bash
docker system df

This shows how much disk space images, containers, and volumes are using, and how many are dangling (unused).

Task 6: Pull from a Different Registry

Try pulling an image from the GitHub Container Registry (ghcr.io) for practice:

bash
docker pull ghcr.io/actions/hello-world:latest

This demonstrates that Docker can use any registry, not just Docker Hub.


Summary

Key Takeaways

  • Docker uses a client-server architecture: the docker CLI (client) talks to dockerd (daemon), which does the heavy lifting.
  • Images are read-only templates composed of layers; containers are runnable instances with a writable layer.
  • Registries store and distribute images; Docker Hub is the default public registry.
  • The basic workflow: client → daemon → registry (if needed) → daemon creates container → output back to client.
  • Commands like docker info, docker history, docker inspect, and docker system df help you explore the architecture and system state.

Check Your Understanding

  1. What are the three main components of Docker architecture?
  2. How does an image differ from a container?
  3. What is the purpose of the writable layer in a container?
  4. If you run docker run -it ubuntu bash and then create a file, where is that file stored? What happens to it when you remove the container?
  5. What command would you use to see the layers of an image?
  6. How does Docker know whether to pull an image from a registry when you run a container?
Click to see answers
  1. Docker Client, Docker Daemon (dockerd), and Docker Registries.
  2. An image is a read-only template/blueprint; a container is a runnable instance created from that image.
  3. The writable layer stores all changes made inside the container (files, configs). It's deleted when the container is removed unless volumes are used.
  4. The file is stored in the container's writable layer. When you remove the container, the file is deleted.
  5. docker history <image>
  6. If the image isn't found locally, the daemon automatically pulls it from the configured registry (default: Docker Hub).

Additional Resources


Next Up

In the next lesson, we'll dive into working with images: pulling, listing, tagging, and removing them. You'll get more hands-on practice with image management. See you there!