Skip to Content
Serveur LinuxPartie 12 — Docker & conteneursVue d'ensemble

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 groupe docker.
  • É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

#ChapitreEn un mot
12.1Pourquoi DockerReproductibilité, conteneur vs VM, les 5 concepts, installer Docker.
12.2Dockerfile pour Next.jsMulti-stage, standalone, .dockerignore, non-root, cache des layers.
12.3docker composeOrchestrer Next + Postgres, volumes persistants, réseaux, secrets.
12.4Docker en productionReverse proxy, restart, registres, logs, mises à jour, nettoyage.
12.5Docker ou bare-metalL’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é.

Last updated on