Pourquoi une checklist avant la prod
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.
Les 10 points en un coup d'œil
- restart: unless-stopped — le conteneur redémarre après un reboot de l'hôte ou un crash
- healthcheck — Docker détecte un conteneur bloqué et permet les redémarrages progressifs
- limites CPU/mémoire — un service emballé ne peut plus asphyxier ses voisins
- secrets via .env ou Docker secrets — jamais de mot de passe en clair dans le fichier Compose
- volumes nommés — les données survivent à un
docker compose down - rotation des logs —
max-sizeetmax-fileempêchent le disque de se remplir - isolation réseau — séparez
frontendetbackend, n'exposez pas tout sur le bridge par défaut - binding de ports —
127.0.0.1:PORTderrière un reverse proxy, pas0.0.0.0 - tags d'image épinglés — une version ou un digest, jamais
latest - depends_on avec condition —
service_healthyévite les courses au démarrage
Prérequis
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.
Les 10 étapes détaillées
1. Politique de redémarrage
Ajoutez restart: unless-stopped à chaque service. Le conteneur redémarre après un crash ou un reboot de l'hôte, mais reste arrêté si vous l'avez stoppé volontairement. Évitez restart: always qui relancerait même un conteneur que vous vouliez laisser à l'arrêt.
2. Healthcheck
Déclarez un bloc healthcheck: avec un test (par exemple curl -f http://localhost:8080/health || exit 1), un interval, un timeout et des retries. Docker marque alors le conteneur healthy ou unhealthy, ce qui permet aux autres services de réagir à un blocage.
3. Limites de ressources
Sous deploy.resources.limits, fixez cpus et memory (par exemple memory: 512M). Sans limite, un service qui fuit peut consommer toute la RAM et faire tuer les autres par l'OOM killer. Ajoutez aussi des reservations pour garantir un minimum.
4. Secrets hors du fichier
Ne mettez jamais un mot de passe en clair dans le YAML. Référencez-les via env_file: .env ou ${VARIABLE}, ou utilisez le mécanisme secrets: de Docker qui monte le secret en fichier dans le conteneur. Ajoutez .env à votre .gitignore.
5. Volumes nommés
Déclarez vos données dans des volumes nommés avec un driver explicite plutôt qu'en bind-mount anonyme. Un volume nommé survit à docker compose down ; seul down -v l'efface. Documentez chaque volume pour savoir ce que vous sauvegardez.
6. Rotation des logs
Ajoutez un bloc logging: avec driver: json-file et des options max-size: "10m" et max-file: "3". Sans cela, les logs d'un conteneur bavard remplissent le disque jusqu'à la panne. Appliquez-le à chaque service.
7. Isolation réseau
Créez des réseaux nommés — un frontend pour ce qui est exposé, un backend pour la base de données — et n'attachez chaque service qu'aux réseaux dont il a besoin. Votre base ne doit être joignable que par l'application, jamais depuis le bridge par défaut partagé.
8. Binding de ports
Derrière un reverse proxy, publiez sur 127.0.0.1:8080:8080 et non 8080:8080 (qui équivaut à 0.0.0.0). Sinon le port reste accessible depuis Internet malgré le proxy, contournant vos règles TLS et d'authentification.
9. Tags d'image épinglés
Remplacez image: postgres:latest par une version précise (postgres:16.3) ou, mieux, par un digest (postgres@sha256:...). latest change sans prévenir et rend vos déploiements non reproductibles. Combinez avec pull_policy: missing pour un comportement prévisible.
10. Ordre de démarrage
Utilisez depends_on avec condition: service_healthy pour qu'un service n'attende pas seulement le lancement mais la disponibilité réelle de sa dépendance. Cela suppose un healthcheck sur le service dépendant (étape 2) et supprime les courses au démarrage.
Défauts de dev contre réglages de prod
| Paramètre | Défaut en dev | Recommandé en prod |
|---|---|---|
| restart | no | unless-stopped |
| healthcheck | absent | défini avec interval et retries |
| mémoire | sans contrainte de nombre | limit fixée (ex. 512M) |
| secrets | en clair possible | .env ou Docker secrets |
| volumes | anonymes | nommés avec driver |
| logs | sans limite | max-size + max-file |
| réseau | bridge par défaut | frontend / backend séparés |
| ports | 0.0.0.0 | 127.0.0.1 derrière proxy |
| image | latest | version ou digest épinglé |
| depends_on | démarrage seul | condition: service_healthy |
Testez toujours votre stack durcie en local avant de la pousser en production : lancez docker compose config pour valider la syntaxe, puis docker compose up et simulez un reboot avec docker compose restart. Vérifiez que les conteneurs reviennent healthy et que les données persistent après un down suivi d'un up.
Dépannage
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é.
Conclusion
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.
