L'équipe a déployé en production avec docker compose up -d sur un serveur privé virtuel : application, worker, cache, proxy inverse. Ça tourne. Six mois plus tard, le premier vrai incident — disque plein sur le nœud unique — coupe tout : web, files d'attente, surveillance. Le plan de reprise parle de « basculer sur le second serveur », mais Compose n'a jamais été configuré pour orchestrer deux hôtes.
Docker Compose excelle à décrire plusieurs conteneurs et leurs liens. Il n'est pas un orchestrateur de datacenter. Confondre « j'ai un fichier yaml qui marche » et « j'ai une infrastructure résiliente » coûte cher au premier point de défaillance unique.
Ce que Compose fait bien — et où ça s'arrête
Compose v2 gère dépendances, contrôles de santé, volumes, réseaux overlay sur un même moteur Docker. Idéal pour reproduire production en local et lancer une stack cohérente.
| Besoin | Compose | Orchestrateur (Kubernetes, Nomad) |
|---|---|---|
| Multi-conteneurs sur 1 hôte | ✅ | ✅ (surdimensionné) |
| Mise à jour progressive sans coupure | ⚠️ manuel / script | ✅ natif |
| Multi-nœud / anti point unique | ❌ | ✅ |
| Autoscaling horizontal | ❌ | ✅ |
| Rotation secrets | ⚠️ limité | ✅ intégré |
Sur un serveur unique chez un hébergeur européen, Compose reste honnête si vous assumez maintenance et sauvegardes hors compose.
Compose documente votre stack ; il ne la rend pas disponible par magie.
Single host, volumes et backups oubliés
Les volumes nommés survivent aux arrêts sans suppression — pratique, dangereux si personne ne snapshot la base. Une mise à jour d'image met à jour l'application mais pas automatiquement la stratégie de sauvegarde du volume PostgreSQL.
Vérifiez : sauvegardes testées hors nœud, surveillance disque et alertes, journaux centralisés — pas seulement journaux conteneur locaux. Externaliser la base réduit le risque sans passer tout de suite à Kubernetes.
Deploy, indisponibilité et contrôle de santé
Sans contrôle de santé, le proxy peut router vers un conteneur qui démarre encore — erreurs serveur temporaires. Pattern : contrôle HTTP sur endpoint applicatif, proxy qui n'envoie le trafic qu'aux backends sains, script de déploiement avec attente de santé.
La mise à jour sans coupure multi-instance sur un seul hôte reste artisanale. C'est là que les limites deviennent concrètes : vous réinventez ce que les orchestrateurs font nativement.
Réseau, TLS et exposition des ports
Publier le port base de données expose PostgreSQL sur Internet si le pare-feu hébergeur est laxiste. Préférez réseau interne compose plus proxy inverse unique sur le port sécurisé.
Observabilité et astreinte nocturne
Compose ne fournit pas de tableau de bord de grappe. Les métriques conteneurs passent par un agent dédié, les journaux par un collecteur — à ajouter explicitement. Documentez qui accède au serveur, comment redémarrer un service, où sont les fichiers d'environnement et qui répond en cas d'alerte à trois heures du matin.
Le sommet : Compose comme dette reportée
Décider et avancer sans angle mort
Si vous restez sur Compose, traitez ces points comme un audit avant le prochain incident :
- Externalisez la base vers une offre managée ou des sauvegardes testées hors nœud — le volume Docker seul ne protège pas vos données.
- Ajoutez des contrôles de santé sur chaque service exposé et configurez le proxy pour n'envoyer le trafic qu'aux backends sains.
- Testez les sauvegardes avec une restauration chronométrée, pas seulement la présence d'un script cron.
- Scriptez le déploiement avec attente de santé et fenêtre de maintenance documentée.
- Déployez une surveillance disque, conteneurs et journaux centralisés — Compose ne le fait pas nativement.
- Planifiez le seuil de migration selon trafic, taille d'équipe et niveau de service promis aux clients.
- Simulez une panne disque : combien de temps pour restaurer service et données ? Si la réponse est floue, Compose n'est pas encore prêt pour vous.
Comparez les hébergeurs adaptés via l'annuaire et le comparateur.
Questions fréquentes
Docker Compose est-il prévu pour la production ?
Compose cible surtout le développement et les déploiements simples sur un ou quelques hôtes. En production à grande échelle, il manque de primitives natives pour la mise à jour progressive multi-nœud, l'autoscaling et la rotation fine des secrets. Cela ne l'interdit pas — mais fixe ses limites.
Quand Compose reste un bon choix ?
Sur un serveur unique, avec une équipe réduite, une stack stable et une tolérance à une courte fenêtre de maintenance. Les outils internes, les MVP et les SaaS early-stage y trouvent souvent leur place — tant que le point de défaillance unique est assumé et documenté.
Comment gérer les secrets avec Compose ?
Utilisez des variables d'environnement via un fichier non versionné, des secrets Docker en mode essaim ou une injection depuis l'intégration continue au déploiement. Ne commitez jamais de mots de passe dans le dépôt. Faites tourner les secrets après toute fuite suspecte.
Comment migrer sans big bang vers Kubernetes ?
Externalisez d'abord l'état (base managée, cache managé), containerisez proprement, puis portez service par service. Compose et Kubernetes peuvent coexister pendant une phase de transition — inutile de tout basculer un vendredi soir.
Compose tient tant que vous pouvez nommer votre point de défaillance unique — et expliquer comment vous le survivez.