Guide
Docker Compose pour une PME : faire tourner ses applications sur un seul serveur, proprement
Docker Compose permet de décrire une application et tout ce dont elle a besoin (l'application elle-même, sa base de données, un processus de fond) dans un seul fichier YAML, puis de tout démarrer d'une commande, docker compose up. Pour une PME, c'est une façon simple et portable de faire tourner plusieurs applications sur un serveur qu'elle maîtrise, à condition de bien régler quelques points de production : politique de redémarrage, contrôles de santé, secrets hors du code, et mises à jour qui remplacent un service à la fois.
Compose, en termes simples
La documentation de Docker présente Compose comme le moyen d'utiliser un fichier de configuration YAML, le fichier Compose, pour configurer les services d'une application, puis de tous les créer et démarrer à partir de cette configuration avec la ligne de commande Compose. Le nom de fichier conseillé est compose.yaml (les anciens noms comme docker-compose.yml fonctionnent toujours).
Le fichier décrit quelques types de briques :
| Brique | Ce que c'est (définitions de Docker, simplifiées) | Exemple |
|---|---|---|
| Service | La même image de conteneur et la même configuration, lancées une ou plusieurs fois | Votre application web, sa base, un processus de fond |
| Réseau | Permet aux services de communiquer entre eux | L'application qui joint sa base par son nom |
| Volume | Un stockage persistant qui survit aux redémarrages | Fichiers de la base, documents téléversés |
| Config | Une configuration qui dépend de la plateforme ou de l'exécution | Un fichier de réglages de l'application |
| Secret | Une configuration sensible qui ne doit pas être exposée | Mot de passe de la base, clés d'API |
Pourquoi cela convient aux PME
Ce n'est pas la réponse à tout. Si vous avez besoin d'une montée en charge automatique sur de nombreuses machines, ou d'une base gérée avec des garanties que vous ne pouvez pas assurer vous-même, une plateforme gérée peut mieux convenir. Pour beaucoup d'applications de PME, un serveur bien tenu suffit.
- Un fichier par application décrit ce qui tourne et comment : un nouveau développeur, ou votre prochain prestataire, peut le lire.
- Portable : le même fichier tourne sur un portable et sur un serveur, ce qui rend un changement d'hébergeur bien moins risqué.
- Plusieurs applications sur un serveur : chacune dans son dossier avec son fichier Compose, derrière un même proxy inverse.
- Pas de dépendance à une plateforme : vous pouvez louer n'importe quel serveur Linux et garder serveur, données et facture à votre nom.
Les réglages qui comptent en production
- Politique de redémarrage : par défaut, Docker ne redémarre pas un conteneur (politique no). Docker propose aussi always, on-failure et unless-stopped ; son guide de production suggère une politique comme restart: always pour éviter les interruptions.
- Contrôles de santé : un healthcheck définit une commande de test lancée à un interval, avec un timeout, un nombre de retries et un start_period. Avec depends_on et condition: service_healthy, un service attend qu'un autre soit déclaré en bonne santé avant de démarrer.
- Secrets et environnement : env_file transmet des variables d'environnement depuis des fichiers ; les valeurs de la section environment sont prioritaires. Les secrets sont montés en lecture seule sous /run/secrets/ dans les conteneurs qui en ont besoin. Ni les uns ni les autres n'ont leur place dans votre dépôt de code.
- Aucun code monté depuis l'extérieur : le guide de production de Docker recommande de retirer les montages de volume du code de l'application, pour que le code reste dans le conteneur et ne puisse pas être modifié de l'extérieur.
- Un fichier de surcharge pour la production : gardez les seules différences de production dans un fichier séparé comme compose.production.yaml, appliqué avec docker compose -f compose.yaml -f compose.production.yaml up -d.
Mettre à jour une application sans toucher aux autres
Le guide de production de Docker montre comment redéployer un seul service après une modification du code : reconstruire son image, puis lancer docker compose up --no-deps -d web, qui arrête, supprime et recrée uniquement le service web ; --no-deps évite de recréer aussi les services dont il dépend. En pratique, nous allons un cran plus loin : les images sont construites ailleurs, sur un service d'intégration continue, et le serveur se contente de récupérer et redémarrer la nouvelle image.
Une routine sûre pour un petit serveur
- Un dossier par application, avec son fichier Compose, un fichier d'environnement d'exemple et un court README.
- Les secrets dans des fichiers d'environnement ou des secrets Compose sur le serveur uniquement, jamais dans Git.
- Des contrôles de santé sur chaque service qui reçoit du trafic, et une page d'état qui les lit.
- Des images construites sur un service d'intégration continue ; le serveur les récupère.
- Des instantanés quotidiens du serveur et des exports réguliers des bases, avec une restauration testée.
- Des mises à jour un service à la fois, en gardant l'image précédente pour un retour arrière rapide.
Notre usage chez Takat
Docker Compose est la façon dont nous faisons tourner notre propre plateforme. Nous avons sorti des applications de Cloud Run et Vercel pour les passer sous Docker Compose, et regroupé plus de 100 projets hébergés sur notre propre serveur. Les compilations tournent sur GitHub Actions, jamais sur le serveur de production ; les services ont des contrôles de santé ; le serveur prend des instantanés quotidiens ; et les mises en ligne ratées sont annulées automatiquement. Chaque projet a ses environnements de dev, de recette et de prod (voir notre guide). Voir Hébergement et DevOps et Migration cloud.
Les questions qu'on nous pose
Docker Compose convient-il à la production ?
Docker publie un guide d'utilisation de Compose en production, avec des changements recommandés : politique de redémarrage, réglages d'environnement différents, aucun code monté depuis l'extérieur du conteneur et fichier de production séparé. Beaucoup d'applications de PME tournent bien ainsi sur un seul serveur.
Quelle est la politique de redémarrage par défaut ?
no : Docker ne redémarre le conteneur en aucun cas, sauf si vous choisissez une autre politique comme always, on-failure ou unless-stopped.
Où mettre les mots de passe et les clés d'API ?
Hors de votre dépôt de code : dans des fichiers d'environnement conservés sur le serveur, ou dans des secrets Compose, montés en lecture seule sous /run/secrets/ dans les conteneurs qui en ont besoin.
Plusieurs applications peuvent-elles partager un serveur ?
Oui. Chaque application a son dossier et son fichier Compose, et un proxy inverse placé devant envoie chaque domaine vers la bonne application. Le serveur doit avoir assez de mémoire et de disque pour toutes, ce que la surveillance doit suivre.
Sources
- Docker Docs : fonctionnement de Compose (modèle d'application, en anglais) (vérifié le 2026-10-06)
- Docker Docs : référence du fichier Compose, services (en anglais) (vérifié le 2026-10-06)
- Docker Docs : utiliser Compose en production (en anglais) (vérifié le 2026-10-06)