Docker Compose en production : checklist des 10 points

Docker Compose a été pensé pour le développement : ses valeurs par défaut privilégient la simplicité, pas la robustesse. Un conteneur ne redémarre pas après un reboot de l'hôte, ses logs grossissent sans limite, il peut consommer toute la RAM de la machine et il écoute sur toutes les interfaces réseau. En production, ces réglages absents se transforment en incidents : disque plein à 3 h du matin, base de données perdue après un docker compose down, service injoignable après une coupure de courant. Durcir une stack Compose ne demande pas de réécriture, seulement une dizaine d'ajouts ciblés. Passez chaque point de cette liste avant de mettre en ligne, et votre service tiendra la charge et les redémarrages sans surveillance constante.

Il vous faut un VPS avec Docker Engine et le plugin Compose v2. La commande est docker compose, sans tiret : vérifiez-la avec docker compose version, car la syntaxe deploy.resources hors Swarm exige Compose v2 (l'ancien docker-compose est traité plus bas). Contrôlez aussi le moteur avec docker version. Docker Engine 29.7.2 corrige CVE-2026-17106 (CopyEscape), une race condition de docker cp divulguée le 10 août 2026 : un conteneur non fiable peut y écraser un fichier de l'hôte, y compris le binaire runc. Côté poste de travail, le correctif est arrivé dans Docker Desktop 4.86.0. En attendant la mise à jour, n'exécutez pas docker cp depuis un conteneur dont vous ne maîtrisez pas le contenu. Rangez le projet dans un dossier dédié (/opt/monapp), avec un .env en chmod 600. Prévoyez un reverse proxy en amont — Traefik, Caddy ou Nginx — car le binding de ports suppose que le trafic public ne touche jamais vos conteneurs, et versionnez le fichier Compose.

Deux outils portent presque le même nom. docker-compose, avec tiret, est Compose v1, écrit en Python : son dépôt le déclare en fin de vie depuis la disponibilité générale de Compose v2, annoncée par Docker le 26 avril 2022. docker compose, avec une espace, est Compose v2, écrit en Go et branché sur la CLI Docker comme plugin. Ubuntu 26.04 achève la transition : le paquet docker-compose n'est plus dans l'archive depuis Ubuntu 25.10, et le paquet docker-compose-v2 n'installe que le plugin, dans /usr/libexec/docker/cli-plugins/. Après la montée de version, tout script qui appelle encore l'ancien nom s'arrête sur docker-compose: command not found. Côté CI, GitHub a sorti Compose v1 de ses runners hébergés le 9 juillet 2024, et fait basculer ubuntu-latest vers Ubuntu 26.04 entre le 19 octobre et le 19 novembre 2026 : un workflow qui installait docker-compose à la main est à revérifier. Deux écarts de comportement sont documentés. Les noms de conteneurs prennent un tiret au lieu d'un tiret bas (monapp-web-1 contre monapp_web_1), sauf avec --compatibility. Et la clé version: est ignorée, avec l'avertissement « the attribute version is obsolete, it will be ignored ».

Un health check utile mesure l'état fonctionnel du service, pas seulement sa disponibilité réseau. Pour une API HTTP, testez un endpoint léger (/health ou /ready) qui ne retourne 200 que si la connexion à la base est établie. Pour PostgreSQL, utilisez pg_isready -U postgres ; pour Redis, redis-cli ping suffit. La colonne STATUS de docker compose ps affiche healthy, unhealthy ou starting. Un conteneur bloqué en starting au-delà de start_period signale un problème d'initialisation : docker compose logs service en donne la cause. Le paramètre start_period est distinct de interval : il ouvre une fenêtre de grâce pendant laquelle les échecs ne comptent pas dans les retries, indispensable aux services qui migrent leur schéma au démarrage.

Hors Swarm, Compose accepte les secrets de type fichier. Déclarez le secret dans la section secrets: au niveau racine, en pointant vers un fichier local (file: ./secrets/db_password.txt), puis référencez-le dans le service avec secrets: [db_password]. Docker monte ce fichier en lecture seule dans /run/secrets/db_password : l'application le lit comme un fichier ordinaire, et sa valeur n'apparaît ni dans les variables d'environnement affichées par docker inspect, ni dans les logs. Pour une rotation, versionnez le secret : créez db_password_v2 à côté de db_password_v1, faites lire v2 au service, redéployez-le seul avec docker compose up -d --no-deps service, puis supprimez v1 une fois le déploiement validé. L'interruption se limite à la recréation de ce conteneur, et l'ancien secret reste disponible pour revenir en arrière.

Le rollback d'une stack Compose se prépare avant le déploiement, pas après l'incident. Gardez l'image précédente taguée et disponible localement : ajoutez un tag explicite monapp:stable avant chaque mise à jour. Pour revenir en arrière, remettez l'ancien tag dans le fichier Compose (ou dans le .env si la version est une variable), puis relancez docker compose up -d. Les volumes ne sont pas touchés par un changement d'image, ce qui rend le retour applicatif rapide ; une migration de schéma, en revanche, doit avoir sa migration inverse prête avant le déploiement. Pour les mises en ligne critiques, séparez docker-compose.yml (version stable) et docker-compose.override.yml (version candidate) : docker compose -f docker-compose.yml up -d ignore l'override et revient à l'état stable.

docker: unknown command: docker compose : le plugin Compose n'est pas installé. Sur Ubuntu, installez docker-compose-v2 depuis l'archive, ou docker-compose-plugin si Docker vient du dépôt officiel de Docker, puis vérifiez avec docker compose version. network not found : après un docker compose down, les réseaux nommés sont supprimés ; un conteneur externe qui tente de les rejoindre échoue. Déclarez les réseaux partagés en external: true ou synchronisez le redémarrage des stacks dépendantes. port is already in use : un autre processus (nginx de l'hôte, stack orpheline) occupe le port. Identifiez-le avec ss -tlnp | grep :PORT puis arrêtez-le. OOM (Out Of Memory) : le kernel tue un conteneur sans prévenir — cherchez OOMKilled: true dans docker inspect container_id, puis relevez deploy.resources.limits.memory ou traquez la fuite avec docker stats. permission denied on volume : le processus du conteneur tourne avec un UID qui n'a pas accès au bind-mount. Vérifiez-le avec docker compose exec service id, puis ajustez le dossier hôte (chown -R UID:GID /chemin) ou ajoutez user: "UID:GID" au service. Conteneur qui redémarre en boucle : docker compose logs --tail=50 service révèle l'erreur de démarrage — le plus souvent une variable d'environnement manquante, un fichier de configuration introuvable ou une dépendance non prête (résolu par depends_on avec service_healthy).

Copier les fichiers d'un volume PostgreSQL ou MySQL à chaud avec rsync ou tar produit presque à coup sûr une sauvegarde corrompue : le moteur écrit pendant la copie, et les pages de données sont capturées à des points de contrôle différents. La règle est de toujours faire un dump SQL avant le snapshot du volume : pg_dump ou mysqldump produisent un état cohérent que vous pouvez archiver ou transférer. Pour automatiser cette approche sur un VPS Docker, des outils comme Restic et Offen Docker Backup orchestrent le gel de la base, le dump SQL, le snapshot chiffré et l'envoi vers un stockage distant. Associez chaque volume nommé de l'étape 5 à une restauration testée.

Ces dix réglages transforment un fichier Compose de développement en une stack capable de survivre aux reboots, aux pics de charge et aux nuits sans surveillance. Health checks, secrets montés en fichier, rollback préparé et passage complet à docker compose complètent ce socle. Rien de tout cela ne demande d'outil supplémentaire : tout tient dans le YAML et les scripts que vous avez déjà. Déroulez la checklist avant chaque mise en ligne, par exemple via une revue de docker compose config intégrée au déploiement. Vous pourrez ensuite ajouter un reverse proxy comme Traefik ou Caddy, ou une couche d'orchestration comme Coolify.