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 sous le capot
• 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

	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
Analogie	Classe (POO) / Moule	Objet / Gâteau fabriqué

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

Analogie : Une image est comme une classe en programmation orientée objet, ou un moule pour faire des gâteaux. Elle définit la structure mais ne s’exécute pas elle-même.

# 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

Analogie : Un conteneur est comme un objet instancié depuis une classe, ou un gâteau fabriqué avec le moule.

# 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

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

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 :

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

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 :

# Ces deux images partagent le layer Ubuntu
docker pull ubuntu:22.04        # Télécharge Ubuntu (~77 Mo)
docker pull nginx:ubuntu        # Réutilise Ubuntu, télécharge nginx (~30 Mo)
# Total : ~107 Mo au lieu de ~154 Mo

→ 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

# 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 ?

Mécanisme	Rôle	Analogie
Namespaces	Isolent ce que le conteneur voit	Murs entre appartements
Cgroups	Limitent ce que le conteneur consomme	Compteurs d’eau/électricité

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 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

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

📝 10 questions

⏱️ 8 min.

🎯 70%

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 ?

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

Pourquoi un conteneur Docker a un PID 1 ?

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

À quoi servent les layers Docker ?

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

À quoi servent namespaces et cgroups dans Docker ?

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

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

×

📖 Voir la documentation →