On a tous fait ça au moins une fois. Tu as un docker-compose.yml qui tourne nickel en local. Tu le balances sur un VPS, tu fais un docker compose up -d, tu respires… et quelques jours plus tard, tu découvres des coupures, des données bizarres, des logs qui explosent, ou pire, une base supprimée « sans comprendre ».
Docker Compose peut aller en prod. Oui. Mais pas en mode freestyle.
1. Confondre « redémarrage automatique » et haute dispo
Le fameux :
yaml restart: always
Ça redémarre le conteneur si ça plante. Point. Ça ne remplace pas un cluster, ça ne répartit pas la charge, ça ne gère pas le multi hôte.
Si ton serveur tombe, tout tombe. Et Compose ne te « failover » rien du tout.
Ce que tu peux faire à la place : être clair sur ton niveau de dispo, ajouter de la supervision, des sauvegardes, et si tu veux du multi nœuds, regarder Kubernetes, Nomad, ou un PaaS.
2. Oublier que les volumes sont ton vrai point de douleur
Le conteneur peut mourir, renaître, s’effacer. Les données, elles, doivent rester.
Piège courant : monter un volume au mauvais endroit, ou utiliser un chemin relatif, puis migrer de serveur et perdre tout.
Exemple solide :
yaml services: db: image: postgres:16 volumes: - /srv/data/postgres:/var/lib/postgresql/data
Et surtout : sauvegarde hors machine. Un volume local sur un VPS, ce n’est pas une sauvegarde.
3. Mettre les secrets en clair dans le fichier Compose
Tu vois le problème :
yaml environment: POSTGRES_PASSWORD: azerty123
Et après ça se retrouve dans l’historique Git, dans des backups, dans des copier coller Slack.
En prod, minimum : fichier .env hors dépôt, permissions strictes. Mieux : Docker secrets (en Swarm) ou un gestionnaire de secrets (Vault, SSM, Doppler).
4. Exposer des ports « pour tester » et oublier de les fermer
Le classique : tu exposes PostgreSQL sur Internet parce que « c’est plus simple » :
yaml ports:
- "5432:5432"
En prod, dans la majorité des cas, tu n’as pas besoin d’exposer la base. Tu la laisses sur le réseau interne Docker et tu n’exposes que le reverse proxy.
5. Ne pas fixer les versions d’images
latest en prod, c’est un abonnement aux surprises.
yaml image: redis:latest
Un jour tu redéploies, et tu récupères un changement de comportement, ou une incompatibilité, ou une migration implicite. Fixe une version, et planifie tes upgrades.
6. Ignorer les healthchecks (et croire que « up » veut dire « prêt »)
Compose peut lancer un service dans l’ordre, mais sans healthcheck, ton app peut démarrer avant que la DB soit vraiment prête.
Ajoute :
yaml healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5
Et fais dépendre le démarrage proprement. Ça évite des bugs fantômes au boot.
7. Laisser les logs remplir le disque
Par défaut, les logs peuvent grossir jusqu’à tuer ton serveur.
Solution simple : rotation côté Docker via le driver json-file avec limites :
yaml logging: driver: "json-file" options: max-size: "10m" max-file: "3"
Sinon, envoie vers Loki, ELK, ou un service géré.
8. Penser que « ça marche en local » implique « ça marche en prod »
Local : peu de charge, latence faible, disque rapide, pas de reboot sauvage, pas de coupures réseau.
Prod : tout ce qui est rare devient fréquent. Un conteneur qui redémarre pendant une écriture, une saturation CPU, une certif TLS expirée.
Tu veux au moins : monitoring, alerting, et un plan de rollback.
9. Utiliser un seul fichier Compose pour tout
Mélanger dev, staging et prod dans le même docker-compose.yml devient vite un piège. Tu finis par activer un service « debug » en prod, ou exposer un port par erreur.
Fais des overrides :
compose.yml(base)compose.prod.yml(prod)
Et lance :
bash docker compose -f compose.yml -f compose.prod.yml up -d
10. Sous estimer le reverse proxy et TLS
Mettre un ports: "80:3000" direct sur ton app, ok pour un test. En prod, tu veux un reverse proxy (Traefik, Nginx, Caddy), du TLS, des headers, des limites.
Et tu veux éviter les certs gérés « à la main » si possible.
11. Oublier les limites de ressources
Sans limites, un conteneur qui part en vrille peut manger toute la RAM et tuer le reste.
Même en Compose, tu peux cadrer un minimum. Selon ton mode (Compose v2, environnement), les limites peuvent dépendre de la configuration Docker, mais l’idée reste : ne laisse pas open bar.
Et surveille réellement la conso.
12. Ne pas tester la restauration, uniquement la sauvegarde
La prod, c’est ça : le jour où tu dois restaurer, tu découvres que la sauvegarde est inutilisable.
Donc tu fais un exercice. Tu restaures sur une machine de test. Tu mesures le temps. Tu notes les étapes. Tu automatises.
C’est moins sexy qu’un nouveau service, mais c’est ce qui évite de perdre une semaine.
petit check rapide avant de dire « c’est bon on push en prod »
- ports exposés au strict nécessaire
- versions d’images figées
- volumes clairs + backup hors serveur
- secrets pas dans Git
- healthchecks
- rotation logs
- reverse proxy + TLS
- monitoring (au moins uptime + disque + RAM)
- procédure de restore testée
Si tu veux, je peux aussi publier un exemple de stack « propre » (Traefik + app + DB + backups + monitoring léger) sur Le Blog Tech Pro de Samyn-Antoy ABASSE sur https://monblog-sa-abasse.blogspot.com, avec un fichier Compose commenté et des variantes selon VPS ou serveur dédié. Ça aide à éviter les erreurs bêtes. Et les erreurs bêtes coûtent cher, justement.
Questions fréquemment posées
Docker Compose est-il adapté pour une utilisation en production ?
Oui, Docker Compose peut être utilisé en production, mais pas en mode freestyle. Il faut suivre certaines bonnes pratiques pour assurer la stabilité, la sécurité et la disponibilité de vos services.
Quelle est la différence entre le redémarrage automatique et la haute disponibilité avec Docker Compose ?
Le paramètre 'restart: always' permet de redémarrer un conteneur s'il plante, mais ne remplace pas un cluster ou la répartition de charge multi-hôtes. Si le serveur tombe, tous les services s'arrêtent. Pour une vraie haute disponibilité, il faut envisager des solutions comme Kubernetes ou Nomad.
Comment gérer efficacement les volumes Docker en production ?
Les volumes sont essentiels pour persister les données. Il faut monter des volumes sur des chemins absolus stables (exemple : /srv/data/postgres:/var/lib/postgresql/data) et surtout effectuer des sauvegardes hors machine car un volume local sur un VPS n'est pas une sauvegarde fiable.
Pourquoi éviter de mettre les secrets en clair dans le fichier docker-compose.yml ?
Mettre des secrets comme les mots de passe directement dans docker-compose.yml expose ces informations sensibles dans l'historique Git, les backups ou même par copier-coller accidentel. Il est préférable d'utiliser un fichier .env hors dépôt avec permissions strictes ou un gestionnaire de secrets comme Docker Secrets, Vault ou Doppler.
Faut-il toujours exposer les ports des services en production ?
Non, il est déconseillé d'exposer directement des ports sensibles comme celui de PostgreSQL sur Internet. En production, on laisse ces services accessibles uniquement sur le réseau interne Docker et on n'expose que le reverse proxy nécessaire à l'extérieur.
Pourquoi est-il important de fixer les versions d'images Docker en production ?
Utiliser l'étiquette 'latest' peut entraîner des surprises lors du redéploiement à cause de changements inattendus dans l'image. Il vaut mieux fixer une version précise d'image (ex: redis:6.2) et planifier les mises à jour pour garder le contrôle sur l'environnement de production.
0 Commentaires