Fundamentals

0.3Architecture: image, container, registry, daemon

Goal: Name Docker's 5 actors and explain their role without jargon.

Estimated time: 10 min · self-paced reading · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

The client orders, the daemon executes: you only talk to the client (docker), the background engine does the work.
The image is the immutable mold, the container the living part: one image → N independent containers, each with its writable layer.
The registry stores tag-versioned images: pull downloads, push publishes — always an explicit tag, never latest in production.

Running mini-case — Idir runs three identical web servers in Algiers

Idir, junior DevOps in Algiers, must test load distribution: instead of reinstalling nginx three times, he applies the architecture. He downloads the image ONCE with docker pull nginx:1.27 (Docker Hub registry, explicit tag), then launches three named containers web1, web2, web3 from that same image. With docker ps, he sees the same image and three independent lives. He removes web2: the image and the other containers survive — living proof that the mold never changes when one part disappears.

Self-contained case for this section: it returns in the lesson, diagram, script and 48h challenge of section 0.3.

1. The five actors

The client (docker) sends orders to the daemon (the background engine). The daemon builds images, stores them locally, downloads them from a registry (Docker Hub) and runs them as containers. You only talk to the client; the daemon does the work. Idir sees the client as the remote control and the daemon as the server.

2. Image vs container: the mold and the part

The image is an immutable template (stack of read-only layers). The container is a living instance of that template, with a thin writable layer on top. You can launch ten containers from the same image without duplicating it: each lives its own life, the image never changes. Idir remembers: removing a container touches neither the image nor its neighbors.

3. The registry, a worldwide library

The registry stores tag-versioned images (nginx:1.27, postgres:16). docker pull downloads, docker push publishes. Docker Hub is the default public registry; companies often add a private registry (GHCR, Harbor). Idir always states his tag: latest freezes no version.

Common misinterpretation: "Image and container are the same thing: I delete the image to stop a container, I stay on latest, and pull is always mandatory". No, triple mistake. The image is the immutable mold, the container the living part: deleting the wrong object breaks the reasoning (you stop a container with stop/rm, not by deleting the image). latest freezes no version: always state the tag. And pull is not mandatory: run downloads the missing image on its own.

The client orders, the daemon executes, the registry stores images.

Text version of the diagram (SEO / screen readers / translation): 1) Idir, junior DevOps in Algiers, names the five actors: he talks to the client (docker), which forwards to the daemon — the engine that builds images, stores them, downloads them from the registry and runs them as containers. 2) He distinguishes mold from part: the image is immutable (read-only layers), the container is a living instance with its writable layer — ten containers from one image each live their own life. 3) He draws from the registry (Docker Hub by default, GHCR or Harbor privately) tag-versioned images (nginx:1.27, postgres:16): pull to download, push to publish, run downloading on its own if needed. Lesson: one image downloaded once, N independent containers — and removing a container erases neither the image nor the others.

🔎 Concrete example — 🔎 Concrete example — Three identical web servers

Idir launches three independent nginx servers from a single image downloaded once.

docker pull nginx:1.27
docker run -d --name web1 nginx:1.27
docker run -d --name web2 nginx:1.27
docker run -d --name web3 nginx:1.27

Reading: a single downloaded image, three independent containers.

Lesson: remove web2: the image and the other containers survive.

Section vocabulary

Client

The docker CLI: it sends orders, it does not execute them.

Simple example: Idir types docker pull nginx:1.27: the client forwards to the daemon.

What it is not: the engine that runs containers.

Reflex: the client orders, the daemon executes.

Daemon

The dockerd engine that truly builds and runs.

Simple example: Idir knows his three web servers run thanks to the daemon.

What it is not: the command typed at the keyboard.

Reflex: nothing starts if the daemon is stopped.

Image

Immutable layered template, identified by name:tag.

Simple example: Idir freezes nginx:1.27: three containers, one intact image.

What it is not: a living, modifiable container.

Reflex: always explicit name:tag.

Container

Living instance of an image, with its writable layer.

Simple example: Idir removes web2: web1 and web3 continue, the image survives.

What it is not: the mold stored in the registry.

Reflex: --name to find your way among neighbors.

Tag

The version label of an image (1.27, 16, latest).

Simple example: Idir picks nginx:1.27 over latest to freeze his version.

What it is not: a container name.

Reflex: latest for testing only, never in production.

In practice — In practice — Seeing the actors in action

Download nginx:1.27 with pull and list your images, like Idir.
Launch two containers from this image with different --name values.
List them with docker ps: same image, two lives.
Remove one: check that the image and the other survive.

You distinguish image, container, registry, client and daemon at first glance.

Step-by-step script — one image, three containers like Idir (5 min)

1) Type docker pull nginx:1.27 then docker images: spot the downloaded image. 2) Type docker run -d --name web1 nginx:1.27 then docker run -d --name web2 nginx:1.27: two lives from the same mold. 3) Type docker ps: check same image, two containers. 4) Type docker rm -f web2 then docker ps and docker images: like Idir, observe that web1 and the image survive.

run downloads the missing image on its own: the explicit pull here is to see the registry in action.

Copy-paste template — my 5-actor memo

docker pull nginx:1.27        # registry → local (explicit tag)
docker images                 # daemon's local stock
docker run -d --name web1 nginx:1.27   # mold → living part
docker ps                     # same image, independent lives
docker rm -f web2            # removing one part, keeping the mold
# Client = remote control / Daemon = server / Registry = library.

Triple web

Idir tests distribution: web1, web2, web3 from nginx:1.27 — one image, three lives.

Versioned database

Idir freezes postgres:16 for his trials: same tag everywhere, reproducible behavior.

Private registry

In a company, Idir will add GHCR or Harbor to the public Hub: same pull, different library.

Stopped container

A stopped container uses disk (layer + logs) with no CPU/RAM: Idir cleans with rm and prune.

✓ Best practices

Always state an explicit version tag.
Name your containers (--name) to find your way.
See the daemon as the "server", the client as the "remote control".

✗ Common pitfalls

Mixing up image and container (deleting one when you want the other).
Using latest thinking it freezes a version.
Believing pull is mandatory (run does it alone).

Key takeaways

The client orders, the daemon executes.
The image is immutable, the container is alive.
The registry stores versioned images.
One image → N independent containers.

48h challenge — apply tomorrow

Replay Idir's trio: pull of nginx:1.27, two named containers, ps to see both lives — then remove one and prove the image and the other survive.

Section exit checklist