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 développement, aucun de ces comportements ne pose problème car vous relancez la stack à la main plusieurs fois par jour. 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. La bonne nouvelle : 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.

Avant d'appliquer cette checklist, assurez-vous de disposer d'un VPS avec Docker Engine et le plugin Compose v2 installés (la commande est docker compose, sans tiret, depuis 2022). Vérifiez la version avec docker compose version : la syntaxe deploy.resources hors Swarm exige Compose v2. Placez votre fichier dans un dossier de projet dédié, par exemple /opt/monapp, avec un fichier .env à côté et des permissions restreintes (chmod 600 .env). Prévoyez un reverse proxy en amont — Traefik, Caddy ou Nginx — car plusieurs réglages, notamment le binding de ports, supposent que le trafic public ne touche jamais directement vos conteneurs. Enfin, gardez une copie de votre fichier Compose sous contrôle de version.

Si un conteneur reste bloqué en état starting, votre healthcheck échoue : testez la commande test manuellement avec docker compose exec service sh et vérifiez qu'elle renvoie bien 0. Un service qui redémarre en boucle (Restarting) cache souvent une erreur au démarrage — consultez docker compose logs -f service. Si deploy.resources.limits semble ignoré, rappelez-vous qu'en Compose v2 hors Swarm les limites sont appliquées, mais les reservations ne le sont qu'en mode Swarm. Un port toujours accessible malgré 127.0.0.1 signale généralement un pare-feu manquant ou une règle Docker qui contourne UFW — vérifiez avec ss -tlnp. Enfin, si un docker compose down a effacé vos données, c'est presque toujours qu'un -v traînait ou que le volume était anonyme plutôt que nommé.

CVE-2026-17106, baptisé CopyEscape, est une race condition dans docker cp divulguée le 10 août 2026. Un conteneur non de confiance peut produire une archive tar incohérente qui suit un lien symbolique hors de la destination, aboutissant à l'écrasement d'un fichier arbitraire sur l'hôte — y compris le binaire runc. La surface : tout VPS exécutant docker cp depuis un conteneur dont vous ne maîtrisez pas le contenu. Le correctif est disponible dans Docker Engine ≥ 29.7.2 et Docker Desktop ≥ 4.86.0. Vérifiez votre version avec docker version et mettez à jour avant d'exposer un nouveau service. Si vous ne pouvez pas mettre à jour immédiatement, évitez docker cp depuis des conteneurs non de confiance et appliquez le principe du moindre privilège (--cap-drop ALL).

Les variables d'environnement en clair dans un fichier Compose sont la première fuite de secrets en production : elles apparaissent dans docker inspect, dans les logs d'erreur et dans les dumps de process. Le mécanisme secrets: de Docker — ou un gestionnaire externe comme Vault ou Infisical — monte les secrets sous forme de fichiers dans /run/secrets/, hors de portée de inspect. Pour une rotation sans downtime, la méthode recommandée est de versionner le secret (créer un nouveau secret db_password_v2 en parallèle du v1), mettre à jour le service pour lire v2, redéployer en rolling update (docker compose up -d --no-deps service), puis supprimer v1 une fois le déploiement validé. Aucune interruption de service, aucune fenêtre de secret exposé entre les deux versions.

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 en continu 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. Documentez chaque volume nommé (étape 5 de la checklist) et associez-lui une stratégie de restauration testée : une sauvegarde sans test de restauration est une donnée non sauvegardée.

Ces dix réglages transforment un fichier Compose de développement en une stack de production capable de survivre aux reboots, aux pics de charge et aux nuits sans surveillance. Aucun ne demande d'outil supplémentaire : tout tient dans le YAML que vous avez déjà. Prenez l'habitude de dérouler cette checklist avant chaque mise en ligne, idéalement sous forme de revue de docker compose config intégrée à votre déploiement. Une fois ces fondations posées, vous pouvez ajouter un reverse proxy comme Traefik ou Caddy, ou une couche d'orchestration comme Coolify, en toute confiance.