02 - L'architecture de Docker

Ce que tu vas apprendre

• Le rôle du Docker daemon et du client
• La différence entre une image et un conteneur
• Ce qu'est un registry et comment Docker y accede
• Le flux complet : pull, build, run
• Le standard OCI et pourquoi il compte

Prerequisites

• Avoir lu l'article 01 - Containers vs VMs
• Docker installe sur ta machine

La première fois que j'ai compris

Pendant longtemps, Docker etait une boîte noire pour moi. Je tapais docker run et ca marchait. Puis un jour, le daemon a plante. Plus rien ne repondait. Je ne comprenais pas pourquoi une simple commande CLI avait besoin d'un service en arriere-plan pour fonctionner.

C'est en comprenant l'architecture client-serveur de Docker que j'ai arrêté de subir les erreurs cryptiques. Quand tu sais ce qui parle a quoi, tu sais ou chercher quand ca casse.

L'architecture client-serveur

Docker repose sur trois composants principaux :

┌──────────────┐     API REST     ┌──────────────┐
│ Docker CLI   │ ───────────────> │ Docker Daemon│
│ (client)     │    /var/run/     │ (dockerd)    │
└──────────────┘    docker.sock   └──────┬───────┘
                                         │
                                   ┌─────┴─────┐
                                   │containerd  │
                                   └─────┬──────┘
                                         │
                                   ┌─────┴─────┐
                                   │  runc      │
                                   └────────────┘

Le client (docker CLI)

C'est ce que tu utilises dans ton terminal. Quand tu tapes docker ps, le client envoie une requête HTTP au daemon via un socket Unix (/var/run/docker.sock). Le client ne fait rien lui-meme. Il traduit tes commandes en appels API.

bash# Ces deux commandes font la meme chose
docker ps
curl --unix-socket /var/run/docker.sock http://localhost/v1.44/containers/json

Le daemon (dockerd)

Le daemon est le cerveau. Il gere les images, les conteneurs, les volumes, les réseaux. Il écoûte les requêtes du client et délégué la création des conteneurs a containerd.

Le daemon tourne en arriere-plan comme un service systemd sur Linux :

bash# Verifier que le daemon tourne
systemctl status docker

# Ou simplement
docker info

Si docker info répond, le daemon est la. Sinon, tu verras l'erreur classique :

Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?

containerd et runc

Le daemon ne créé pas directement les conteneurs. Il délégué a containerd, qui lui-meme utilise runc pour créer le conteneur via les appels système Linux (namespaces, cgroups).

Cette séparation existe parce que Docker a voulu rendre ses composants remplacables. Tu peux utiliser containerd sans Docker. Kubernetes l'utilise directement depuis la version 1.24.

Images vs conteneurs

C'est la confusion la plus courante chez les débutants. Et certains devs experimentent gardent le flou.

Une image est un template en lecture seule. Elle contient le système de fichiers, les librairies, et la configuration de ton application. Elle ne tourne pas.

Un conteneur est une instance d'une image. Il tourne, il a un processus, il consomme des ressources. Tu peux créer plusieurs conteneurs à partir de la meme image.

bash# Telecharge l'image
docker pull nginx

# Cree et lance un conteneur a partir de l'image
docker run -d --name web1 nginx
docker run -d --name web2 nginx

# Deux conteneurs, meme image
docker ps

L'analogie classique : l'image est la classe, le conteneur est l'instance. Ca tient a peu pres.

Le registry

Un registry est un serveur qui stocke des images Docker. Le plus connu est Docker Hub. Quand tu fais docker pull nginx, Docker va chercher l'image sur Docker Hub.

Le flux complet :

bash# 1. Cherche l'image localement
# 2. Si pas trouvee, la telecharge depuis le registry
# 3. Cree un conteneur
# 4. Lance le conteneur
docker run nginx

Tu peux aussi utiliser d'autres registries :

bash# GitHub Container Registry
docker pull ghcr.io/owner/image:tag

# Google Artifact Registry
docker pull us-docker.pkg.dev/project/repo/image:tag

# AWS ECR
docker pull 123456789.dkr.ecr.eu-west-1.amazonaws.com/image:tag

Le registry par défaut est docker.io (Docker Hub). Si tu ne specifies pas de registry, c'est celui-la qui est utilise.

Le flux build

Quand tu construis une image avec un Dockerfile, voici ce qui se passe :

bashdocker build -t mon-app .

1. Le client envoie le build context (le répertoire .) au daemon
2. Le daemon lit le Dockerfile instruction par instruction
3. Chaque instruction créé une couche (layer)
4. Les couches sont empilees pour former l'image finale
5. L'image est stockee localement

On verra les couches en détail dans l'article 05. Pour l'instant, retiens que chaque ligne du Dockerfile ajoute une couche.

Le flux run

bashdocker run -d -p 8080:80 --name web nginx

1. Le daemon cherche l'image nginx localement
2. Si absente, il la telecharge depuis Docker Hub
3. Il créé un conteneur (nouveau système de fichiers, couche writable)
4. Il configure le réseau (mapping du port 8080 vers 80)
5. Il demande a containerd de lancer le processus

Le conteneur tourne tant que son processus principal (PID 1) est vivant.

Le standard OCI

OCI signifie Open Container Initiative. C'est la spec qui definit le format des images et le runtime des conteneurs. Docker a donne son runtime (runc) a l'OCI en 2015.

Pourquoi c'est utile pour toi ? Parce que ca veut dire qu'une image construite avec Docker fonctionne avec Podman, containerd, ou n'importe quel runtime OCI. Tu n'es pas enferme dans l'ecosysteme Docker.

bash# Construire avec Docker
docker build -t mon-app .

# Lancer avec Podman (sans Docker daemon)
podman run mon-app

Sur paltemps.fr, on construit les images avec Docker en local et elles tournent sur des clusters qui utilisent containerd. Le standard OCI rend ca transparent.

Les commandes de base pour explorer

bash# Voir les images locales
docker images

# Voir les conteneurs en cours
docker ps

# Voir tous les conteneurs (y compris arretes)
docker ps -a

# Inspecter un conteneur
docker inspect <container_id>

# Voir les logs
docker logs <container_id>

# Supprimer un conteneur arrete
docker rm <container_id>

# Supprimer une image
docker rmi <image_id>

Résumé

• Docker fonctionne en client-serveur : le CLI envoie des requêtes au daemon
• Le daemon délégué a containerd puis runc pour créer les conteneurs
• Une image est un template en lecture seule, un conteneur est une instance en cours d'exécution
• Les registries stockent les images (Docker Hub par défaut)
• Le standard OCI garantit la portabilité des images entre runtimes

Precedent : 01 - Containers vs VMs | Suivant : 03 - Desktop & Engine

Sources

• Docker architecture - docs.docker.com
• Open Container Initiative
• containerd - containerd.io