Partie 12 — Docker & conteneurs
⏱️ TL;DR — Jusqu’ici tu as tout installé à la main sur le VPS : Node, PHP, Postgres, Nginx, chacun avec sa version et ses fichiers de config posés sur la machine. Ça marche, mais c’est fragile et difficile à reproduire : le fameux « ça marche chez moi ». Docker change la donne en empaquetant ton app avec son environnement (le bon Node, les bonnes libs, la bonne config) dans une image que tu fais tourner à l’identique en dev, en CI et en prod. Dans cette partie, tu comprends image / conteneur / volume / réseau / registre, tu écris un Dockerfile propre pour Next.js, tu orchestres front + API + Postgres avec
docker compose, tu fais tourner tout ça proprement en prod (reverse proxy, redémarrage, logs, nettoyage), et tu décides honnêtement : Docker ou bare-metal ?
Le problème qu’on résout
Ton app tourne. Sur ton portable, sur le VPS après une installation manuelle soignée. Puis les ennuis commencent :
- Un collègue clone le repo et rien ne démarre : il n’a pas la même version de Node, il lui manque une lib système, sa base locale est configurée autrement.
- Tu montes un deuxième serveur et tu dois refaire à la main toute l’installation, en espérant ne rien oublier.
- Tu mets à jour Node sur le VPS pour un projet et tu casses un autre projet qui tournait sur l’ancienne version.
- L’environnement de dev et celui de prod ont divergé sans que personne ne s’en rende compte, et un bug n’apparaît qu’en prod.
La racine commune : ton application dépend d’un environnement (versions, libs, variables, config) qui vit en dehors du code, posé à la main sur chaque machine, et donc jamais tout à fait le même. Docker rend cet environnement explicite, versionné et reproductible : il vit dans un fichier (le Dockerfile), il se construit en une commande, il tourne à l’identique partout. C’est la reproductibilité qui tue le « ça marche chez moi ».
Ce que tu sauras faire à la fin de cette partie
- Expliquer ce qu’est un conteneur (et en quoi il diffère d’une VM), et nommer les cinq concepts clés : image, conteneur, volume, réseau, registre.
- Installer Docker Engine proprement sur Ubuntu (dépôt officiel, plugin
compose) et connaître le risque de sécurité du groupedocker. - Écrire un Dockerfile multi-stage pour Next.js qui produit une image légère, non-root et cacheable.
- Orchestrer plusieurs services (front Next + API Symfony + Postgres) avec un
compose.yaml, en persistant les données et en n’exposant que le nécessaire. - Faire tourner Docker en production : reverse proxy devant les conteneurs, redémarrage au boot, logs bornés, registres, mises à jour et nettoyage du disque.
- Arbitrer entre Docker et une installation bare-metal, sans dogme, selon ton projet.
Les chapitres
| # | Chapitre | En un mot |
|---|---|---|
| 12.1 | Pourquoi Docker | Reproductibilité, conteneur vs VM, les 5 concepts, installer Docker. |
| 12.2 | Dockerfile pour Next.js | Multi-stage, standalone, .dockerignore, non-root, cache des layers. |
| 12.3 | docker compose | Orchestrer Next + Postgres, volumes persistants, réseaux, secrets. |
| 12.4 | Docker en production | Reverse proxy, restart, registres, logs, mises à jour, nettoyage. |
| 12.5 | Docker ou bare-metal | L’arbitrage honnête, coûts, arbre de décision, tableau comparatif. |
Cette partie te rend capable de conteneuriser ton app et de la faire tourner en prod avec docker compose. La Partie 13 — CI/CD & automatiser enchaînera naturellement : une fois l’app dans une image, la construire et la déployer automatiquement à chaque merge devient bien plus simple.
On commence : Pourquoi Docker — de « ça marche chez moi » à la reproductibilité.