L’image est un colis figé : une pile de couches en lecture seule, des métadonnées (utilisateur, variables, point d’entrée) et un identifiant de contenu. Elle ne s’exécute pas. Elle se construit, se pousse, se tire.
Le conteneur est une instance de cette image. Docker ajoute une couche d’écriture, isole le processus (namespaces) et lui alloue des ressources (cgroups). C’est ce qui démarre, s’arrête, écrit des logs et meurt.
Une image, beaucoup de conteneurs. Tous partagent les mêmes couches de lecture ; chacun a sa propre couche d’écriture et son propre PID 1.
image (immuable) → docker run → conteneur (instance)
couches RO couche RW + processusQue vous ne dites pas « un conteneur, c’est une petite machine virtuelle ». La question sert à entendre le partage du noyau et l’immuabilité de l’image. Si vous savez expliquer qu’on ne « répare » pas une image en se connectant dedans — on reconstruit, on retague, on redéploie — vous avez déjà le réflexe de production.
Le piège junior : confondre docker commit avec une façon de travailler. Ça existe, ça produit une image depuis un conteneur modifié, et c’est exactement ce qu’on ne veut plus revoir : un artefact sans Dockerfile, impossible à reconstruire.
« Que se passe-t-il si je supprime l’image alors qu’un conteneur tourne encore ? »
Le conteneur continue : il tient déjà les couches dont il a besoin. Vous ne pourrez plus en lancer un nouveau depuis cette référence locale. Ce n’est pas une raison de supprimer des images à la légère sur un hôte partagé.
« L’image change-t-elle quand le conteneur écrit un fichier ? »
Non. L’écriture va dans la couche du conteneur, ou dans un volume. L’image reste identique. C’est pour ça qu’on peut tuer un conteneur et le relancer « propre » : tout ce qui n’était pas dans un volume disparaît.