Chapitre 12.4 — Docker en production

⏱️ TL;DR — Faire tourner docker compose up sur ton portable, c’est une chose. Le faire tenir en production en est une autre. Quatre chantiers : un reverse proxy devant les conteneurs (le Nginx de l’hôte qui proxifie le port publié en local, ou un proxy conteneurisé type Traefik qui fait le HTTPS tout seul) ; la résilience (restart: unless-stopped + Docker qui démarre au boot, pour que tout remonte après un reboot ou un crash) ; le déploiement par registre (pull la nouvelle image → up -d) ; et l’hygiène (logs bornés pour ne pas saturer le disque, docker system prune pour vider les images mortes, mises à jour prudentes). Fil rouge sécurité : ne jamais exposer le socket Docker, qui vaut root sur l’hôte.

🎯 Objectifs

• Placer un reverse proxy devant les conteneurs (Nginx hôte ou proxy conteneurisé).
• Garantir le redémarrage au boot et après crash (restart + service docker activé).
• Déployer une nouvelle version via un registre (pull puis up -d).
• Borner les logs des conteneurs pour ne pas remplir le disque.
• Nettoyer les images/volumes orphelins (docker system prune).
• Comprendre les mises à jour automatiques (Watchtower) et leurs risques.
• Ne jamais exposer le socket Docker.

Un reverse proxy devant, toujours

On ne publie jamais un conteneur applicatif directement sur le port 80/443 d’Internet. Comme en Partie 7, un reverse proxy se tient en façade : il termine le TLS (HTTPS), route selon le domaine, et relaie vers le conteneur. Deux approches, selon que le proxy vit sur l’hôte ou dans un conteneur.

Option A — Le Nginx de l’hôte (le plus simple)

Tu gardes le Nginx installé sur le VPS (celui des Parties 7-8, avec Certbot pour le HTTPS). Ton compose.yaml publie le front sur 127.0.0.1:3000 (localhost seulement), et Nginx proxifie vers ce port local — exactement comme il le ferait pour une app lancée par systemd. Docker devient un détail d’implémentation invisible pour Nginx.

server {
    listen 443 ssl;
    server_name formacampus.fr;
 
    # ... configuration TLS gérée par Certbot ...
 
    location / {
        proxy_pass http://127.0.0.1:3000;   # le conteneur publié en local
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

💡 Réflexe — Si tu as déjà un Nginx hôte maîtrisé (config, HTTPS, logs), garde-le : conteneuriser l’app ne t’oblige pas à conteneuriser le proxy. Tu réutilises tout ton acquis des Parties 7-8, et le conteneur n’est qu’un proxy_pass de plus. C’est l’option la plus progressive pour un dev qui débute avec Docker.

Option B — Un proxy conteneurisé (Traefik, Nginx Proxy Manager)

Ici, le proxy est lui-même un conteneur dans le compose.yaml. Traefik est le plus connu : il découvre automatiquement les autres conteneurs via leurs labels, génère les routes et obtient les certificats Let’s Encrypt tout seul. On configure le routage dans le compose.yaml, pas dans un fichier Nginx séparé :

  web:
    build: .
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.web.rule=Host(`formacampus.fr`)"
      - "traefik.http.routers.web.tls.certresolver=letsencrypt"
    networks:
      - internal

Avantage : tout (routage et HTTPS) vit dans la stack, versionné avec le reste, idéal quand tu as plein de services à exposer. Inconvénient : une courbe d’apprentissage (les labels Traefik, ça se dompte) et un composant de plus à comprendre. Nginx Proxy Manager offre une alternative avec interface web pour ceux qui préfèrent cliquer.

⚠️ Piège — Deux proxys qui se marchent dessus. Si tu lances un proxy conteneurisé (Traefik) alors que le Nginx de l’hôte écoute déjà sur 80/443, le second ne pourra pas démarrer (« port déjà utilisé »). Choisis une stratégie : soit Nginx hôte + conteneurs publiés en local, soit proxy conteneurisé qui prend 80/443 et un hôte qui ne fait pas tourner Nginx dessus. Pas les deux.

La résilience : tout doit remonter tout seul

Deux mécanismes complémentaires garantissent qu’après un incident, la stack revient d’elle-même.

1. La politique de redémarrage des conteneurs. Dans chaque service, restart: unless-stopped dit à Docker : « redémarre ce conteneur s’il crashe ou au démarrage du démon, sauf si je l’ai arrêté explicitement ». C’est l’équivalent conteneur du Restart=always de systemd (Partie 9). Sans ça, un conteneur qui plante reste mort.

2. Docker lui-même doit démarrer au boot. Le démon Docker est un service systemd : s’il n’est pas activé, aucun conteneur ne remontera après un reboot du VPS — même avec la meilleure politique restart.

# Vérifier que Docker démarre au boot (souvent déjà le cas après l'install officielle)
sudo systemctl enable --now docker
sudo systemctl is-enabled docker    # doit répondre : enabled

⚠️ Piège — restart: unless-stopped sans le service docker activé au boot = illusion de résilience. Le conteneur redémarrerait après un crash de l’app, mais pas après un reboot du serveur, car Docker lui-même ne serait pas relancé. Vérifie systemctl is-enabled docker : les deux conditions doivent être vraies. C’est le pendant conteneur du piège « j’ai oublié enable » de systemd.

Déployer une nouvelle version

En prod, on ne builde généralement pas sur le serveur : on construit l’image en CI, on la pousse dans un registre (Docker Hub, GHCR…), et le serveur la tire. Le déploiement se résume alors à :

# Sur le VPS, dans le dossier de la stack
docker compose pull        # tire les nouvelles versions des images depuis le registre
docker compose up -d       # recrée seulement les conteneurs dont l'image a changé
docker image prune -f      # supprime les anciennes images désormais inutilisées

Compose est malin : up -d ne recrée que les services dont l’image (ou la config) a réellement changé, et laisse les autres tourner. Postgres n’est pas touché parce que tu redéploies le front. La Partie 13 automatisera exactement cette séquence à chaque merge.

💡 Réflexe — Tague tes images avec une version (formacampus-web:1.4.0), pas seulement latest. En prod, latest est ambigu (« la dernière quoi ? ») et rend les rollbacks impossibles : si la 1.4.0 casse, tu redéploies la 1.3.0 en une ligne. Avec latest, tu ne sais même plus ce qui tournait.

Les logs : les borner avant qu’ils ne saturent le disque

Par défaut, Docker écrit les logs de chaque conteneur dans un fichier json-file qui grossit sans limite. Un conteneur bavard peut remplir le disque en quelques jours et faire tomber tout le VPS. On borne les logs — par conteneur, ou globalement via le fichier de config du démon.

// /etc/docker/daemon.json — configuration globale du démon Docker
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Ici, chaque conteneur garde au plus 3 fichiers de 10 Mo (rotation automatique), soit 30 Mo max par conteneur. Après modification, sudo systemctl restart docker applique la config (elle ne s’applique qu’aux conteneurs recréés ensuite).

⚠️ Piège — le disque qui se remplit en silence. C’est la panne Docker sournoise. Entre les logs non bornés, les images accumulées à chaque build/pull, les volumes orphelins et le cache de build, le disque du VPS se remplit progressivement, sans alerte, jusqu’au jour où plus rien ne démarre (« no space left on device »). Surveille df -h (Partie 14), borne les logs, et nettoie régulièrement (ci-dessous).

Le nettoyage : garder le disque sain

Docker accumule. Chaque build laisse des images intermédiaires, chaque pull d’une nouvelle version rend l’ancienne inutile, des volumes et réseaux orphelins traînent. On fait le ménage :

# Voir combien Docker occupe (images, conteneurs, volumes, cache de build)
docker system df
 
# Supprimer conteneurs arrêtés, réseaux inutilisés, images ORPHELINES, cache
docker system prune
 
# Version plus agressive : supprime aussi les images non utilisées par un conteneur
docker system prune -a
 
# Nettoyer uniquement les images inutilisées
docker image prune -a

🔒 Sécurité — prune et les volumes. docker system prune ne touche pas aux volumes par défaut (heureusement — tes données de base y sont). Il faut --volumes pour les inclure, et là tu risques d’effacer des données si un volume utile est temporairement détaché. Ne mets jamais --volumes dans un prune automatisé sans savoir précisément ce qui va disparaître. Le ménage des images est sûr ; celui des volumes demande de la vigilance.

Les mises à jour automatiques : Watchtower, avec prudence

Watchtower est un conteneur qui surveille les registres et met à jour automatiquement tes conteneurs quand une nouvelle image paraît. Séduisant sur le papier, risqué en prod : une mise à jour non testée peut casser ton service sans que tu l’aies décidé, en pleine nuit. On le cite pour la culture ; en production maîtrisée, on préfère un déploiement explicite (via la CI), où tu choisis quand et quelle version part. Watchtower peut convenir pour des services non critiques ou du homelab, pas pour la prod d’une plateforme comme FormaCampus.

Le socket Docker : à ne jamais exposer

Le socket Docker (/var/run/docker.sock) est le point d’entrée du démon. Qui y a accès contrôle Docker, donc l’hôte entier (souviens-toi : le groupe docker vaut root, chapitre 12.1).

🔒 Sécurité — le socket Docker vaut root. Ne monte jamais /var/run/docker.sock dans un conteneur exposé au public « pour qu’il pilote Docker », et ne l’expose jamais sur le réseau. Un conteneur qui a le socket peut lancer n’importe quel autre conteneur, monter le disque de l’hôte, et prendre le contrôle total du VPS. Certains outils (Traefik, portainer, Watchtower) le demandent en lecture seule pour découvrir les conteneurs — ne l’accorde qu’à des composants de confiance, jamais à ce qui traite des requêtes publiques, et jamais en écriture si tu peux l’éviter.

🧭 Sur FormaCampus — En prod, FormaCampus retient l’option A : le Nginx de l’hôte (déjà en place depuis les Parties 7-8, avec Certbot) proxifie vers le front conteneurisé publié sur 127.0.0.1:3000 et l’API sur 127.0.0.1:8000. Chaque service porte restart: unless-stopped, et docker est activé au boot : un reboot du VPS remonte toute la plateforme seule. Le déploiement (piloté par la Partie 13) fait docker compose pull && docker compose up -d avec des images taguées par version (rollback possible). Les logs sont bornés (daemon.json, 10 Mo × 3), un docker system prune hebdomadaire (sans --volumes) tient le disque au propre, surveillé par le df -h du monitoring (Partie 14). Watchtower ? Écarté : les mises à jour partent de la CI, quand l’équipe le décide.

✏️ Exercices

Exercice 1 — Le site ne remonte pas après reboot. Après un redémarrage du VPS, aucun conteneur ne tourne, alors que tous ont restart: unless-stopped. Quelle est la cause probable, et comment la vérifier/corriger ?

Exercice 2 — « No space left on device ». Le VPS ne démarre plus de conteneur, le disque est plein. Docker occupe 40 Go. Quelles commandes pour diagnostiquer puis récupérer de l’espace sans risquer les données ?

Exercice 3 — Choisir le proxy. Ton VPS fait déjà tourner un Nginx hôte avec Certbot pour un autre site. Tu ajoutes une app conteneurisée. Traefik conteneurisé ou Nginx hôte ? Justifie.

🧠 Quiz de révision

Chapitre suivant : Docker ou bare-metal — l’arbitrage honnête, sans hype.