Concepts Docker : images, conteneurs, layers, cycle de vie et architecture

Ce que vous allez apprendre

• Image vs Conteneur : la différence fondamentale que tout débutant doit maîtriser
• Cycle de vie : les états created, running, paused, stopped, dead
• Layers : pourquoi Docker est si efficace (cache, partage, téléchargement)
• Isolation : namespaces et cgroups, les mécanismes du kernel Linux mis en jeu
• Architecture : client, daemon, registry, comment tout s'articule

En 30 secondes

Concept	Définition express
Image	Modèle immuable (read-only) composé de layers
Conteneur	Processus isolé + layer R/W (éphémère par défaut)
docker run	Crée puis démarre un conteneur (create → start)
États	created → running ↔ paused → exited → removed
Daemon	dockerd orchestre via API ; le client docker envoie des requêtes
Layers	Chaque instruction Dockerfile = une couche partagée et cachée

Glissez pour voir

Testé avec

Ce guide a été validé avec Docker Engine 24.0+ sur Ubuntu 22.04 et Debian 12. Les concepts s'appliquent à toutes les versions récentes.

Prérequis

Installer Docker Si Docker n'est pas encore installé sur votre machine

Notions Linux Comprendre les processus et le filesystem aide

Quelle est la différence entre image et conteneur ?

La distinction entre image et conteneur est la notion la plus importante à maîtriser. C'est la question que se posent tous les débutants, et la source de nombreuses confusions.

La réponse courte

Le tableau se lit ligne par ligne, et la première, Nature, contient tout le reste. Une image est un modèle inerte posé sur le disque ; un conteneur est ce modèle en train de s'exécuter, avec un processus vivant. La ligne Multiplicité est celle qui débloque la compréhension : à partir d'une seule image, vous lancez autant de conteneurs que voulu, chacun indépendant. Gardez ce rapport un vers plusieurs en tête, il explique pourquoi supprimer un conteneur ne touche jamais à l'image dont il est issu.

	Image	Conteneur
Nature	Modèle immuable	Instance (processus)
Écriture	Read-only	Layer R/W
Persistance	Stockée sur disque	Éphémère sans volume
Multiplicité	1 image → N conteneurs	1 conteneur = 1 exécution

Glissez pour voir

L'image : le modèle immuable

Une image Docker est un package en lecture seule contenant tout le nécessaire pour exécuter une application :

• Système de fichiers de base (OS minimal)
• Dépendances et bibliothèques
• Code de l'application
• Variables d'environnement
• Commande de démarrage

Caractéristiques clés :

Propriété	Description
Immuable	Une fois créée, une image ne change jamais
Versionnée	Identifiée par un tag (ex: nginx:1.25)
Portable	Fonctionne identiquement partout
Composée de layers	Chaque instruction Dockerfile = une couche

Glissez pour voir

# Lister les images locales
docker images

# Télécharger une image depuis Docker Hub
docker pull nginx:alpine

# Inspecter une image
docker inspect nginx:alpine

Le conteneur : l'instance en exécution

Un conteneur est une instance d'une image en cours d'exécution. C'est un processus isolé avec son propre :

• Système de fichiers (copie de l'image + layer d'écriture)
• Espace réseau
• Arborescence de processus (PID)
• Hostname

Caractéristiques clés :

Propriété	Description
Éphémère	Par défaut, les données disparaissent à la suppression
Isolé	Séparé des autres conteneurs et de l'hôte
Layer R/W	Peut écrire dans sa couche propre (non persistante)
Léger	Partage le kernel avec l'hôte

Glissez pour voir

# Créer et démarrer un conteneur
docker run -d --name web nginx:alpine

# Lister les conteneurs en cours
docker ps

# Lister tous les conteneurs (y compris arrêtés)
docker ps -a

→ Pour manipuler images et conteneurs : Guide CLI Docker

Image → Conteneur : le flux

Une image, plusieurs conteneurs

Une même image peut instancier des dizaines de conteneurs simultanés. Chaque conteneur a son propre état mais partage les layers en lecture de l'image.

Que fait exactement docker run ?

Quand vous exécutez docker run nginx:alpine, Docker effectue plusieurs opérations en séquence :

1. Recherche l'image localement, sinon la télécharge (docker pull)

2. Crée un conteneur avec un layer R/W (docker create)

3. Configure l'isolation : namespaces, cgroups, réseau

4. Démarre le processus principal (docker start)

C'est pourquoi docker run = docker create + docker start.

# Équivalent à docker run -d --name web nginx:alpine
docker create --name web nginx:alpine
docker start web

Cycle de vie d'un conteneur

Un conteneur passe par plusieurs états au cours de sa vie. Comprendre ces états vous permet de diagnostiquer rapidement pourquoi un conteneur ne fonctionne pas comme prévu.

Diagramme des états

Le schéma ci-dessous relie les cinq états par les commandes qui font passer de l'un à l'autre. Suivez surtout la double flèche entre running et paused : c'est la seule transition réversible sans perte, le processus reste en mémoire. Toutes les autres flèches vont dans un sens de dégradation, jusqu'à removed qui est définitif. Repérez aussi que created et exited mènent tous deux à running par docker start, ce qui explique qu'un conteneur arrêté puisse redémarrer sans être recréé.

Les états détaillés

created

Le conteneur est créé mais pas démarré. Le layer R/W existe, les ressources sont allouées, mais aucun processus ne tourne.

# Créer sans démarrer
docker create --name myapp nginx:alpine

# Vérifier l'état
docker ps -a --filter "name=myapp"
# STATUS: Created

Cas d'usage : préparer un conteneur avec des configurations avant démarrage.

running

Le conteneur est actif, son processus principal (PID 1) s'exécute.

# Démarrer un conteneur créé
docker start myapp

# Ou créer et démarrer directement
docker run -d --name web nginx:alpine

# Vérifier
docker ps
# STATUS: Up 5 seconds

paused

Le processus est suspendu (signal SIGSTOP). Le conteneur reste en mémoire mais ne consomme plus de CPU.

# Mettre en pause
docker pause myapp

# Reprendre
docker unpause myapp

Cas d'usage : debugging, snapshot mémoire, migration live.

stopped / exited

Le processus principal s'est terminé (normalement ou avec erreur). Le conteneur et son layer R/W existent toujours.

# Arrêter proprement (SIGTERM puis SIGKILL après 10s)
docker stop myapp

# Arrêter immédiatement (SIGKILL)
docker kill myapp

# Voir le code de sortie
docker inspect myapp --format '{{.State.ExitCode}}'

Différence entre docker stop et docker kill ?

Commande	Signal	Délai	Usage
docker stop	SIGTERM → SIGKILL	10s par défaut	Arrêt propre (graceful)
docker kill	SIGKILL	Immédiat	Forcer l'arrêt

Glissez pour voir

Règle : utilisez toujours docker stop sauf si le conteneur ne répond plus.

Comment savoir pourquoi un conteneur est en Exited (137) ?

Code de sortie	Signification
0	Succès, le processus s'est terminé normalement
1-125	Erreur application
126	Commande non exécutable
127	Commande non trouvée
137	SIGKILL (OOM killer ou docker kill)
143	SIGTERM (docker stop)

Glissez pour voir

# Diagnostiquer un exit 137
docker logs myapp              # Voir les derniers logs
docker inspect myapp | grep -i oom  # Vérifier si OOM
dmesg | grep -i "killed process"    # Vérifier OOM killer

→ Pour approfondir le troubleshooting : Commandes Docker CLI

dead

État d'erreur où le conteneur ne peut pas être redémarré ni supprimé normalement. Généralement causé par un problème de ressources ou de driver de stockage.

# Forcer la suppression
docker rm -f myapp

Commandes et transitions

Ce tableau est la version texte du schéma précédent, pratique comme aide-mémoire. Une entrée mérite l'attention : docker restart enchaîne un arrêt puis un démarrage (running → exited → running), il ne s'agit donc pas d'une reprise à chaud. Le processus est réellement terminé puis relancé depuis zéro, ce qui remet à plat tout état conservé en mémoire mais préserve le layer R/W sur disque.

Commande	Transition
docker create	→ created
docker start	created/exited → running
docker run	→ created → running
docker pause	running → paused
docker unpause	paused → running
docker stop	running → exited
docker kill	running → exited
docker restart	running → exited → running
docker rm	exited → removed

Glissez pour voir

Pourquoi Docker utilise des layers ?

Docker utilise un système de couches (layers) pour les images, optimisant le stockage et les téléchargements. C'est ce qui rend Docker si efficace.

Principe des layers

Chaque instruction d'un Dockerfile crée une couche. Le Dockerfile ci-dessous est découpé instruction par instruction pour rendre ce découpage visible : le apt-get update isolé dans sa propre couche est à ne pas reproduire en production, il transporte l'index des paquets et casse le cache au premier changement de version.

# Layer 1 : image de base
FROM ubuntu:22.04
# Layer 2 : cache apt
RUN apt-get update
# Layer 3 : nginx installé
RUN apt-get install -y nginx
# Layer 4 : fichiers application
COPY app/ /var/www/

Les 4 avantages du système de layers

Avantage	Description	Impact
Partage	Les layers communs sont partagés entre images	Économie disque
Cache	Les layers inchangés sont réutilisés lors du build	Builds rapides
Téléchargement	Seuls les layers manquants sont téléchargés	Réseau optimisé
Immutabilité	Chaque layer a un hash unique	Reproductibilité

Glissez pour voir

Exemple de partage : l'image officielle nginx est construite au-dessus de debian. Si la base est déjà présente localement, Docker ne la retélécharge pas et l'annonce par Already exists au lieu de Pull complete.

# Après avoir déjà récupéré la base Debian
docker pull debian:bookworm-slim

# nginx réutilise les layers Debian déjà présents
docker pull nginx:latest
# <id-layer-base>   Already exists   ← layer de base Debian, non retéléchargé
# <id-layer-nginx>  Pull complete    ← layers propres à nginx
# ...

Chaque layer affiché est identifié par une empreinte : deux images qui partagent exactement le même layer de base affichent le même identifiant, et le contenu n'existe qu'une fois sur le disque.

→ Pour optimiser vos builds : Écrire un Dockerfile

Copy-on-Write (CoW)

Quand un conteneur modifie un fichier d'un layer en lecture seule :

1. Docker copie le fichier dans le layer R/W du conteneur
2. Les modifications s'appliquent à la copie
3. Le layer original reste intact

Performance CoW

Les écritures fréquentes dans des fichiers de l'image (logs, bases de données) peuvent être lentes à cause du CoW. Utilisez des volumes pour les données qui changent souvent.

→ Pour la persistance des données : Volumes Docker

Pourquoi les données disparaissent quand je supprime un conteneur ?

Le layer R/W (lecture/écriture) du conteneur est éphémère. Quand vous supprimez le conteneur (docker rm), ce layer disparaît avec toutes les données écrites.

Solutions pour persister les données :

Méthode	Usage	Commande
Volume nommé	Bases de données, fichiers importants	-v mydata:/var/lib/data
Bind mount	Développement (code source)	-v ./src:/app
docker commit	Sauvegarder l'état (rarement recommandé)	docker commit container image

Glissez pour voir

Inspecter les layers

docker history reconstitue la pile de couches d'une image, une ligne par instruction du Dockerfile d'origine, de la plus récente (en haut) à la base (en bas). La colonne SIZE est celle à surveiller : elle révèle quelle instruction alourdit l'image, souvent un RUN apt-get qui laisse un cache. Ajoutez --no-trunc pour lire la commande complète, tronquée par défaut, et docker inspect ... .RootFS.Layers pour obtenir les empreintes qui servent à repérer les layers partagés entre plusieurs images.

# Voir les layers d'une image
docker history nginx:alpine

# Détails avec tailles
docker history --no-trunc nginx:alpine

# Inspecter le système de fichiers
docker inspect nginx:alpine --format '{{json .RootFS.Layers}}'

Isolation : namespaces et cgroups

Docker utilise deux mécanismes du kernel Linux pour isoler les conteneurs. Comprendre ces mécanismes vous aide à diagnostiquer les problèmes et à renforcer la sécurité.

À quoi servent namespaces et cgroups ?

Ces deux mécanismes du kernel répondent à deux questions différentes, et les confondre mène à de mauvais diagnostics. Retenez la formule du tableau : les namespaces gèrent la visibilité (ce que le conteneur perçoit du système), les cgroups gèrent la consommation (la part de ressources qu'il a le droit d'utiliser). Un conteneur qui voit les processus de l'hôte a un problème de namespace ; un conteneur tué pour dépassement mémoire a un problème de cgroup. Les deux sections suivantes détaillent chacun.

Mécanisme	Rôle
Namespaces	Isolent ce que le conteneur voit
Cgroups	Limitent ce que le conteneur consomme

Glissez pour voir

Namespaces

Les namespaces créent des vues isolées des ressources système :

Namespace	Isole	Effet
PID	Processus	Le conteneur voit ses propres PIDs (1, 2, 3...)
Network	Réseau	Interface réseau, IP, ports propres
Mount	Filesystem	Points de montage indépendants
UTS	Hostname	Hostname et domainname propres
IPC	IPC	Mémoire partagée, sémaphores isolés
User	Utilisateurs	Mapping UID/GID (rootless mode)

Glissez pour voir

Visualisation :

# PID dans le conteneur
docker run --rm alpine ps aux
# PID 1 = processus principal

# PID vu depuis l'hôte
docker top <container_id>
# PID réel sur l'hôte (ex: 12345)

Pourquoi un conteneur a un PID 1 ?

Dans un conteneur, le processus principal devient PID 1 grâce au namespace PID. Ce processus :

• Reçoit les signaux (SIGTERM, SIGKILL)
• Doit gérer les processus orphelins (reaping)
• Sa mort = arrêt du conteneur

Tini pour les signaux

Si votre application ne gère pas bien les signaux, utilisez tini comme init minimaliste : docker run --init ...

Cgroups

Les cgroups (control groups) limitent et comptabilisent les ressources :

Ressource	Option docker run	Exemple
CPU	--cpus	--cpus 0.5 (50% d'un CPU)
Mémoire	--memory	--memory 256m
I/O	--device-read-bps	Limiter lecture disque
PIDs	--pids-limit	Nombre max de processus

Glissez pour voir

# Limiter les ressources
docker run -d --memory 128m --cpus 0.5 nginx:alpine

# Voir les limites d'un conteneur
docker stats --no-stream

Docker : conteneur vs VM, quelle différence ?

Critère	Conteneur	VM
Isolation	Kernel partagé (namespaces/cgroups)	Hyperviseur (isolation matérielle)
Démarrage	Secondes	Minutes
Taille	Mo	Go
Overhead	Minimal	Significatif (OS complet)
Sécurité	Surface d'attaque plus large	Isolation plus forte

Glissez pour voir

Conteneurs ≠ VMs

Les conteneurs partagent le kernel de l'hôte. L'isolation est logicielle (namespaces/cgroups), pas matérielle comme les VMs. C'est plus léger mais avec une surface d'attaque différente.

→ Pour renforcer l'isolation : Sécuriser Docker

Architecture Docker

Docker utilise une architecture client-serveur où le client communique avec le daemon via une API REST.

Vue d'ensemble

Le schéma matérialise la séparation client / daemon, la clé de toute l'architecture. Quand vous tapez docker ps, la commande ne fait rien elle-même : elle envoie une requête sur une API REST au daemon dockerd, qui exécute réellement le travail et renvoie le résultat. Cette séparation explique deux choses concrètes, développées juste après : pourquoi le client peut piloter un daemon distant, et pourquoi l'accès au socket du daemon équivaut à un accès root sur la machine.

Le daemon dockerd

Le daemon Docker (dockerd) est le cœur du système :

• Écoute sur le socket Unix /var/run/docker.sock
• Gère les images, conteneurs, réseaux et volumes
• S'exécute en root par défaut (attention sécurité)
• Communique avec containerd pour l'exécution

# Vérifier que le daemon tourne
sudo systemctl status docker

# Voir les logs du daemon
sudo journalctl -u docker.service

# Le processus
ps aux | grep dockerd

Pourquoi le groupe docker équivaut à root ?

Socket Docker = accès root

Toute personne ayant accès au socket Docker (/var/run/docker.sock) peut potentiellement obtenir un accès root sur l'hôte. Comment ? En montant le filesystem de l'hôte dans un conteneur :

# Un utilisateur du groupe docker peut faire ça :
docker run -v /:/hostroot -it alpine chroot /hostroot
# → Shell root sur l'hôte !

Règle : n'ajoutez au groupe docker que les utilisateurs de confiance, ou utilisez le mode rootless.

Le client docker

Le client est l'outil en ligne de commande que vous utilisez :

• Envoie des requêtes au daemon via l'API REST
• Peut se connecter à un daemon distant
• Configuration dans ~/.docker/config.json

# Communiquer avec un daemon distant
export DOCKER_HOST=tcp://remote-host:2376
docker ps

# Voir la configuration client
cat ~/.docker/config.json

Les registries

Un registry stocke et distribue les images Docker :

Registry	Type	Usage
Docker Hub	Public	Registry par défaut, images officielles
GitHub Container Registry	Public/Privé	Intégré à GitHub
Harbor	Privé	Enterprise, on-premise
AWS ECR	Privé	AWS natif
Google Artifact Registry	Privé	GCP natif

Glissez pour voir

# Télécharger depuis Docker Hub (par défaut)
docker pull nginx

# Télécharger depuis un autre registry
docker pull ghcr.io/owner/image:tag

# Pousser vers un registry
docker push myregistry.com/myimage:v1

Résumé visuel

Ce diagramme synthétise l'écosystème Docker : les images (templates), les conteneurs (instances), les volumes (persistance), le daemon qui orchestre le tout, et le kernel Linux partagé qui rend cette légèreté possible.

À retenir

1. Image = modèle immuable : template read-only composé de layers
2. Conteneur = instance éphémère : processus isolé avec son propre layer R/W
3. docker run = create + start : recherche l'image, crée le conteneur, démarre
4. Cycle de vie : created → running ↔ paused → exited → removed
5. Layers : chaque instruction Dockerfile = une couche partagée et cachée
6. Namespaces : isolation des vues système (PID, network, mount...)
7. Cgroups : limitation des ressources (CPU, mémoire, I/O)
8. Socket Docker = root : protégez /var/run/docker.sock

Contrôle des connaissances

Ce quiz cible les confusions classiques du débutant : image contre conteneur, sens des transitions du cycle de vie, rôle respectif des namespaces et des cgroups. Comptez huit minutes et visez 70 %. Si vous butez sur les questions d'états, revenez au diagramme du cycle de vie, c'est là que se logent la plupart des erreurs.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Prochaines étapes

Commandes Docker CLI Mettez en pratique ces concepts avec les commandes de base

Volumes Docker Rendez vos données persistantes avec les volumes

Réseaux Docker Comprenez comment les conteneurs communiquent

Sécuriser Docker Approfondissez namespaces, cgroups et isolation

FAQ, Questions fréquentes

Quelle est la différence entre une image et un conteneur Docker ?

Une image Docker est un modèle immuable (read-only) composé de layers, contenant code et dépendances. Un conteneur est une instance en exécution de cette image, avec son propre layer R/W éphémère. Une image peut créer plusieurs conteneurs.

Quelle est la différence entre un conteneur Docker et une VM ?

Un conteneur partage le kernel Linux de l'hôte via namespaces/cgroups (léger, démarre en secondes). Une VM embarque un OS complet avec son propre kernel via un hyperviseur (plus lourd, démarre en minutes, isolation matérielle plus forte).

Pourquoi un conteneur Docker a un PID 1 ?

Grâce au namespace PID, chaque conteneur a sa propre vue des processus. Le processus principal devient PID 1, reçoit les signaux SIGTERM/SIGKILL, et sa mort arrête le conteneur. Utilisez --init avec tini si votre app gère mal les signaux.

Quelle est la différence entre docker stop et docker kill ?

docker stop envoie SIGTERM puis attend 10 secondes avant SIGKILL (arrêt propre, graceful shutdown). docker kill envoie SIGKILL immédiatement (arrêt brutal). Utilisez toujours stop sauf si le conteneur ne répond plus.

À quoi servent les layers Docker ?

Les layers permettent le partage (images avec la même base partagent les couches), le cache (rebuild rapide si layer inchangé), et l'optimisation réseau (seuls les layers manquants sont téléchargés). Chaque instruction Dockerfile crée un layer.

Pourquoi les données disparaissent quand je supprime un conteneur Docker ?

Le layer R/W du conteneur est éphémère. Quand vous supprimez le conteneur avec docker rm, ce layer disparaît avec toutes les données écrites. Solution : utilisez des volumes (-v mydata:/data) pour persister les données importantes.

À quoi servent namespaces et cgroups dans Docker ?

Les namespaces isolent ce que le conteneur voit (PID, réseau, filesystem, hostname). Les cgroups limitent ce qu'il consomme (CPU, mémoire, I/O). Ensemble, ils créent l'isolation des conteneurs sans hyperviseur, directement dans le kernel Linux.

Pourquoi l'accès au socket Docker est dangereux ?

Le socket /var/run/docker.sock donne un accès équivalent à root sur l'hôte. Un utilisateur peut monter le filesystem de l'hôte dans un conteneur et obtenir un shell root. N'ajoutez au groupe docker que les utilisateurs de confiance.

Comment savoir pourquoi un conteneur est en Exited (137) ?

Le code 137 signifie SIGKILL (128 + 9). Causes possibles : docker kill, OOM killer (mémoire insuffisante), ou arrêt forcé. Vérifiez avec docker logs, docker inspect | grep -i oom, et dmesg | grep killed.

×

📖 Voir la documentation →