0.3Architecture : image, conteneur, registre, daemon
L'essentiel en 30 secondes
- Le client ordonne, le daemon exécute : vous ne parlez qu'au client (docker), le moteur de fond fait le travail.
- L'image est le moule immuable, le conteneur la pièce vivante : une image → N conteneurs indépendants, chacun avec sa couche inscriptible.
- Le registre stocke les images versionnées par tags : pull télécharge, push publie — toujours un tag explicite, jamais latest en production.
Mini-cas filé — Idir fait tourner trois serveurs web identiques à Alger
Idir, devops junior à Alger, doit tester la répartition de charge : au lieu de réinstaller trois fois nginx, il applique l'architecture. Il télécharge UNE fois l'image avec docker pull nginx:1.27 (registre Docker Hub, tag explicite), puis lance trois conteneurs nommés web1, web2, web3 depuis cette même image. Avec docker ps, il voit la même image et trois vies indépendantes. Il supprime web2 : l'image et les autres conteneurs survivent — la preuve vivante que le moule ne change jamais quand une pièce disparaît.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 0.3.
1. Les cinq acteurs
Le client (docker) envoie des ordres au daemon (le moteur de fond). Le daemon construit des images, les stocke localement, en télécharge depuis un registre (Docker Hub) et les exécute en conteneurs. Vous ne parlez qu'au client ; le daemon fait le travail. Idir voit le client comme la télécommande et le daemon comme le serveur.
2. Image vs conteneur : le moule et la pièce
L'image est un modèle immuable (empilement de couches en lecture seule). Le conteneur est une instance vivante de ce modèle, avec une fine couche inscriptible par-dessus. On peut lancer dix conteneurs de la même image sans la dupliquer : chacun vit sa vie, l'image ne change jamais. Idir retient : supprimer un conteneur ne touche ni l'image ni ses voisins.
3. Le registre, bibliothèque mondiale
Le registre stocke les images versionnées par tags (nginx:1.27, postgres:16). docker pull télécharge, docker push publie. Docker Hub est le registre public par défaut ; les entreprises ajoutent souvent un registre privé (GHCR, Harbor). Idir précise toujours son tag : latest ne fige aucune version.
🔎 Exemple concret — 🔎 Exemple concret — Trois serveurs web identiques
Idir lance trois nginx indépendants depuis une seule image téléchargée une fois.
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.27Lecture : une seule image téléchargée, trois conteneurs indépendants.
Leçon : supprimez web2 : l'image et les autres conteneurs survivent.
Vocabulaire de la section
- Client
- La CLI docker : elle envoie des ordres, ne les exécute pas.
Exemple simple : Idir tape docker pull nginx:1.27 : le client transmet au daemon.
Ce que ce n'est pas : le moteur qui exécute les conteneurs.
Réflexe : le client ordonne, le daemon exécute.
- Daemon
- Le moteur dockerd qui construit et exécute vraiment.
Exemple simple : Idir sait que ses trois web tournent grâce au daemon.
Ce que ce n'est pas : la commande tapée au clavier.
Réflexe : rien ne démarre si le daemon est arrêté.
- Image
- Modèle immuable en couches, identifié par nom:tag.
Exemple simple : Idir fige nginx:1.27 : trois conteneurs, une seule image intacte.
Ce que ce n'est pas : un conteneur vivant et modifiable.
Réflexe : toujours nom:tag explicite.
- Conteneur
- Instance vivante d'une image, avec sa couche inscriptible.
Exemple simple : Idir supprime web2 : web1 et web3 continuent, l'image survit.
Ce que ce n'est pas : le moule stocké au registre.
Réflexe : --name pour s'y retrouver entre voisins.
- Tag
- L'étiquette de version d'une image (1.27, 16, latest).
Exemple simple : Idir choisit nginx:1.27 plutôt que latest pour figer sa version.
Ce que ce n'est pas : un nom de conteneur.
Réflexe : latest en test seulement, jamais en production.
En pratique — En pratique — Voir les acteurs en action
- Téléchargez nginx:1.27 avec pull et listez vos images, comme Idir.
- Lancez deux conteneurs de cette image avec des --name différents.
- Listez-les avec docker ps : même image, deux vies.
- Supprimez-en un : vérifiez que l'image et l'autre survivent.
Script pas-à-pas — une image, trois conteneurs comme Idir (5 min)
1) Tapez docker pull nginx:1.27 puis docker images : repérez l'image téléchargée. 2) Tapez docker run -d --name web1 nginx:1.27 puis docker run -d --name web2 nginx:1.27 : deux vies depuis le même moule. 3) Tapez docker ps : vérifiez même image, deux conteneurs. 4) Tapez docker rm -f web2 puis docker ps et docker images : comme Idir, constatez que web1 et l'image survivent.
run télécharge seul l'image manquante : le pull explicite sert ici à voir le registre en action.
Modèle copier-coller — mon mémo des 5 acteurs
docker pull nginx:1.27 # registre → local (tag explicite)
docker images # stock local du daemon
docker run -d --name web1 nginx:1.27 # moule → pièce vivante
docker ps # même image, vies indépendantes
docker rm -f web2 # supprimer une pièce, garder le moule
# Client = télécommande / Daemon = serveur / Registre = bibliothèque.Triple web
Idir teste la répartition : web1, web2, web3 depuis nginx:1.27 — une image, trois vies.
Base versionnée
Idir fige postgres:16 pour ses essais : même tag partout, comportement reproductible.
Registre privé
En entreprise, Idir ajoutera GHCR ou Harbor au Hub public : même pull, autre bibliothèque.
Conteneur arrêté
Un conteneur arrêté occupe du disque (couche + logs) sans consommer CPU/RAM : Idir nettoie avec rm et prune.
✓ Bonnes pratiques
- Précisez toujours un tag de version explicite.
- Nommez ses conteneurs (--name) pour s'y retrouver.
- Voyez le daemon comme le « serveur », le client comme la « télécommande ».
✗ Pièges fréquents
- Confondre image et conteneur (supprimer l'un en voulant l'autre).
- Utiliser latest en pensant figer une version.
- Croire que pull est obligatoire (run le fait seul).
Points clés à retenir
- Le client ordonne, le daemon exécute.
- L'image est immuable, le conteneur est vivant.
- Le registre stocke les images versionnées.
- Une image → N conteneurs indépendants.
Défi 48h — appliquez demain
Rejouez le trio d'Idir : pull de nginx:1.27, deux conteneurs nommés, ps pour voir les deux vies — puis supprimez-en un et prouvez que l'image et l'autre survivent.
- Je peux citer les 5 acteurs et le rôle de chacun sans jargon.
- J'ai lancé N conteneurs depuis une seule image taguée.
- Je sais ce qui survit quand je supprime un conteneur (image + voisins).
Questions fréquentes
Où sont stockées mes images ?
En local, dans l'espace du daemon (docker images). La copie de référence vit dans le registre distant tant qu'on ne l'a pas pull — Idir vérifie en local après chaque pull.
Un conteneur arrêté consomme-t-il des ressources ?
Presque pas de CPU/RAM, mais il occupe du disque (sa couche + ses logs). On nettoie avec rm et prune — Idir purge les coquilles au lieu de les accumuler.
Quelle image décrit le mieux le couple image / conteneur ?