Image, conteneur, Dockerfile : la trinité
Résumé : ces trois mots reviennent en boucle dès qu'on parle de Docker, et 8 débutants sur 10 les confondent. Cette leçon les distingue une bonne fois pour toutes avec une analogie de restaurant, puis détaille le cycle de vie complet — de l'écriture du Dockerfile jusqu'au conteneur qui répond aux requêtes.
1. L'analogie du restaurant
Imaginez un restaurant qui propose des lasagnes. Cette activité met en scène trois choses très différentes :
Le mapping avec Docker :
| Objet du restaurant | Équivalent Docker |
|---|---|
| La recette écrite | Dockerfile — un fichier texte qui décrit comment construire l'image |
| Le plat cuisiné, prêt à servir | Image Docker — le résultat de la construction, en lecture seule |
| L'assiette servie au client | Conteneur Docker — une instance de l'image en cours d'exécution |
Vous pouvez servir plusieurs assiettes du même plat. De la même manière, on peut lancer plusieurs conteneurs à partir de la même image — c'est comme cela que Netflix ou Uber font tourner des milliers de copies identiques de leurs services.
2. Le Dockerfile — la recette
Un Dockerfile est un simple fichier texte qui décrit, étape par étape, comment construire l'image. Il vit à côté du code source de l'application, versionné dans Git.
Exemple ultra-simple (pas besoin de le retenir, on veut juste voir à quoi ça ressemble) :
FROM node:20-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
Décodage ligne par ligne, en français :
| Instruction | Ce qu'elle dit à Docker |
|---|---|
FROM node:20-alpine | Pars de l'image officielle Node.js version 20 sur Alpine Linux |
WORKDIR /app | Positionne-toi dans le dossier /app |
COPY package.json . | Copie mon fichier package.json dans le conteneur |
RUN npm install | Installe toutes les dépendances |
COPY . . | Copie tout mon code source |
EXPOSE 3000 | Signale que l'application écoute sur le port 3000 |
CMD ["node", "server.js"] | Lance la commande de démarrage |
Ce fichier est la source unique de vérité : chaque personne qui construit l'image à partir de ce Dockerfile obtient rigoureusement la même image. Fin du « ça marche sur ma machine ».
3. L'image — le plat cuisiné
Une image Docker est le résultat de la construction d'un Dockerfile. C'est un artefact en lecture seule, comme un fichier ZIP scellé qui contient tout ce qu'il faut pour faire tourner l'application.
Point crucial pour bien comprendre : une image est immutable. Une fois construite, elle ne change pas. Si vous voulez modifier l'application, vous construisez une nouvelle image avec un nouveau tag (comme monapp:v2.4.0) — l'ancienne reste disponible.
Cette immutabilité est la clé de la reproductibilité. Si je vous dis « lance l'image nginx:1.27.1-alpine », vous et moi obtenons exactement les mêmes octets, où que nous soyons dans le monde.
4. Le système de couches — la trouvaille géniale
L'invention la plus astucieuse de Docker, c'est le système de couches (layers).
Chaque instruction du Dockerfile crée une couche, empilable comme des feuilles de papier calque.
Bénéfices concrets de cette architecture :
- Cache de construction : si vous modifiez uniquement votre code source (couche 4), Docker réutilise les couches 1, 2 et 3 sans les reconstruire. La reconstruction prend 2 secondes au lieu de 5 minutes.
- Partage entre images : si dix images utilisent la même base Node.js, cette couche est stockée une seule fois sur le disque. Économies massives.
- Distribution efficace : lors d'un téléchargement depuis Docker Hub, seules les couches manquantes sont récupérées.
C'est ce système qui rend Docker si rapide et si économe en disque malgré la quantité d'images en circulation.
5. Le conteneur — l'assiette servie
Un conteneur est l'exécution vivante d'une image. C'est ce qui tourne réellement, qui utilise du CPU et de la RAM, qui répond aux requêtes.
Qu'est-ce qui rend un conteneur unique, s'il part de la même image que les autres ?
- Son cycle de vie : il peut être démarré, arrêté, redémarré, supprimé.
- Son état volatile : les fichiers créés à l'intérieur pendant son exécution (par exemple, des uploads utilisateurs) disparaissent à sa suppression — sauf si on utilise un volume pour les persister.
- Son identifiant : chaque conteneur a un ID unique et souvent un nom lisible (par exemple
webapp-prod-1). - Sa configuration au lancement : variables d'environnement, ports mappés, volumes montés, réseau attaché.
Analogie utile : l'image est comme la classe en programmation orientée objet. Le conteneur est comme une instance de cette classe. On peut créer beaucoup d'instances à partir d'une seule classe.
6. Le cycle de vie complet
Voici le voyage complet, du texte au conteneur qui répond en production.
Ce cycle est le fondement de tout usage professionnel de Docker. En CI/CD, il est automatisé : un git push déclenche la construction de l'image, son publication dans le registre, et le déploiement sur les serveurs de production — le tout sans intervention humaine, en moins de 10 minutes.
7. Où vivent les images — le registre
Le registre (registry) est le catalogue central où les images sont publiées et récupérées.
Docker Hub est à Docker ce que GitHub est à Git : le lieu où la communauté partage ses artefacts, où les grands projets open source publient leurs images officielles (Nginx, PostgreSQL, Redis, Python, Node…), et où votre équipe peut publier ses images privées.
Un simple docker pull postgres:16 télécharge en quelques secondes une base de données PostgreSQL prête à l'emploi. C'est cette accessibilité qui a démocratisé le déploiement d'infrastructures complexes.
8. La question qui piège en entretien
« Est-ce qu'une image est un conteneur arrêté ? »
Réponse courte : non.
Réponse développée : une image est un template en lecture seule. Elle ne peut pas être « démarrée » — elle sert de moule à des conteneurs. Un conteneur arrêté, lui, existe toujours en tant qu'entité avec son propre état (dernières modifications de fichiers, journaux…). On peut le redémarrer avec docker start.
Autre piège : « pourquoi mes fichiers ont disparu après un docker run ? »
Réponse : parce que les fichiers créés dans un conteneur sont perdus à sa suppression. Pour persister les données (base de données, uploads), il faut utiliser un volume — c'est un des sujets clés du Cours Premium Docker.
Retenir en 30 secondes
- Dockerfile = la recette (fichier texte, versionné dans Git).
- Image = le plat cuisiné (artefact immutable, en couches, publiable dans un registre).
- Conteneur = l'assiette servie (instance en cours d'exécution, avec un cycle de vie).
- Un Dockerfile construit une image. Une image instancie un conteneur. Un registre partage les images.
- Le système de couches est ce qui rend Docker rapide et économe en disque.
- Docker Hub = « le GitHub des images Docker » — 15 millions d'images publiques.
Suivant : Docker vs machine virtuelle : la comparaison qui éclaire tout →