Docker Compose transforme une pile de conteneurs en un système que l’on peut démarrer, reconstruire et diagnostiquer avec quelques commandes. Comprendre les options de docker compose up, c’est gagner du temps sans perdre de vue les enjeux de configuration, de persistance et de fiabilité.
L’article en bref
Docker Compose simplifie l’orchestration d’une application composée de plusieurs services, à condition de maîtriser les commandes et leurs effets. Voici les repères pour démarrer proprement, préserver les données et résoudre les problèmes courants.
- Démarrage maîtrisé : Lancez tous les services avec les options adaptées à votre environnement.
- Images à jour : Distinguez reconstruction, téléchargement et recréation des conteneurs.
- Données préservées : Gérez les volumes avec prudence lors de l’arrêt du projet.
- Dépannage efficace : Validez la configuration et consultez les journaux au bon moment.
Une commande courte devient fiable lorsqu’on comprend précisément ce qu’elle modifie.
Docker Compose up : démarrer plusieurs conteneurs en une commande
Dans une application réelle, lancer séparément une API, une base de données et un serveur web multiplie les commandes et les risques d’écart entre environnements. Docker Compose rassemble leur configuration dans un fichier YAML versionnable, puis coordonne leur démarrage selon les services déclarés.
Un petit service de réservation, par exemple, peut réunir une interface web, une API et PostgreSQL. La commande docker compose up crée les ressources nécessaires et démarre cette pile ; elle ne remplace toutefois ni une stratégie de sécurité ni une supervision adaptée.
La commande up et ses options courantes
Exécutée sans option, docker compose up affiche les journaux dans le terminal et le garde attaché au processus. Pour poursuivre d’autres tâches, le démarrage en arrière-plan s’effectue avec l’option -d : docker compose up -d.
Compose compare alors le fichier de configuration aux ressources existantes. Il crée ce qui manque et peut reconstruire ou recréer certains conteneurs lorsque les modifications l’exigent. Ce comportement facilite le développement, mais mérite d’être vérifié avant une opération sensible.
Choisir entre reconstruction et recréation
L’option –build demande à Compose de construire les images avant le démarrage : docker compose up –build -d. Elle est utile après une modification du Dockerfile ou du code copié dans l’image, mais ne signifie pas que toutes les données persistantes seront remplacées.
Pour recréer les conteneurs même si Compose les juge inchangés, utilisez –force-recreate. À l’inverse, –no-recreate conserve les conteneurs déjà présents. Il faut distinguer la reconstruction des images, la recréation des conteneurs et la suppression des volumes : ce sont trois opérations différentes.
Dans une équipe, cette distinction évite une erreur classique : reconstruire l’image pour intégrer une modification ne nécessite pas automatiquement d’effacer la base de données. Le choix de l’option doit suivre le changement visé, et non une habitude de commande.
Docker Compose et fichiers YAML : structurer les services
La configuration décrit principalement les services, les réseaux et les volumes. Chaque service correspond à un rôle de l’application et peut préciser une image, des ports, des variables d’environnement ou des dépendances.
La syntaxe YAML dépend de l’indentation : deux espaces sont une convention simple et fiable, tandis que les tabulations provoquent souvent des erreurs de lecture. Le fichier s’appelle généralement compose.yaml ou docker-compose.yml ; la commande moderne fonctionne avec les deux formats de nom courants.
Les commandes de gestion à connaître
Une fois la pile lancée, quelques commandes couvrent l’essentiel des opérations quotidiennes. Le tableau distingue leur fonction afin d’éviter de confondre inspection, exécution et arrêt.
| Commande | Utilité | Exemple d’usage |
|---|---|---|
| docker compose ps | Consulter l’état des conteneurs du projet | Vérifier quels services sont actifs |
| docker compose logs -f | Suivre les journaux en temps réel | Observer le démarrage d’une API |
| docker compose exec | Exécuter une commande dans un conteneur actif | Ouvrir un client SQL dans la base |
| docker compose run –rm | Lancer une tâche ponctuelle dans un conteneur temporaire | Exécuter des tests ou une migration |
| docker compose config | Vérifier et afficher la configuration interprétée | Repérer une variable manquante |
| docker compose down | Arrêter et supprimer les conteneurs du projet | Nettoyer la pile sans supprimer les volumes |
Pour lancer une migration, par exemple, docker compose run –rm api npm run migrate crée un conteneur éphémère dédié à cette tâche. Pour entrer dans un service déjà actif, docker compose exec db psql -U postgres évite au contraire de créer un nouveau conteneur.
Vérifier la configuration avant le lancement
docker compose config résout les paramètres et révèle la configuration que Compose va utiliser. C’est un réflexe de dépannage efficace lorsque les variables d’environnement ne sont pas substituées comme prévu ou qu’une erreur YAML empêche le démarrage.
Les mots de passe et ports personnalisables peuvent être externalisés dans un fichier .env. Ce fichier local doit être exclu du dépôt Git ; un fichier d’exemple sans secret permet aux collègues de reproduire l’environnement sans exposer d’identifiants.
Gestion des volumes et arrêt sans perte de données
Les volumes nommés conservent les données au-delà de la suppression d’un conteneur. Ils sont particulièrement utiles pour les bases de données : un volume attaché à PostgreSQL permet de recréer le service sans repartir automatiquement d’un stockage vide.
La commande docker compose down arrête et supprime les conteneurs et les réseaux créés pour le projet, mais conserve généralement les volumes nommés. L’option -v demande aussi leur suppression : docker compose down -v. Avant de l’utiliser, vérifiez qu’aucune donnée à conserver ne dépend de ces volumes.
Réseaux et disponibilité des services
Par défaut, les services d’un même projet peuvent communiquer sur un réseau Compose et utiliser leur nom comme nom d’hôte. Une API se connectera ainsi à la base via db, plutôt que via une adresse IP susceptible de changer.
depends_on organise certaines dépendances de démarrage, mais ne garantit pas qu’une base de données accepte déjà les connexions. Pour éviter qu’une API tente de se connecter trop tôt, définissez un healthcheck sur la base et utilisez une condition de disponibilité lorsque la configuration Compose le permet. L’ordre de création ne remplace pas un contrôle de santé.
Astuces Docker Compose pour le développement et le dépannage
Un projet gagne en clarté lorsqu’il sépare la configuration commune des ajustements locaux. Un fichier de base peut décrire les services et leurs dépendances, tandis qu’un fichier d’override ajoute, pour le développement, un montage du code source ou un port de débogage.
Compose peut charger automatiquement un fichier docker-compose.override.yml dans les configurations conventionnelles, ou recevoir explicitement plusieurs fichiers avec -f. Il est prudent de vérifier le résultat fusionné avec docker compose config, notamment avant de reproduire la configuration en production.
Une méthode simple pour diagnostiquer un échec
Quand un service ne démarre pas, mieux vaut examiner les faits dans l’ordre plutôt que relancer toute la pile à l’aveugle. Ces vérifications permettent de localiser rapidement une erreur de syntaxe, un problème d’image ou une dépendance indisponible.
- Valider le YAML avec docker compose config et contrôler les variables substituées.
- Examiner l’état des conteneurs avec docker compose ps, y compris ceux qui se sont arrêtés.
- Lire les journaux du service concerné avec docker compose logs api ou l’option -f.
- Vérifier la disponibilité des dépendances, notamment la base et ses contrôles de santé.
- Recréer uniquement si nécessaire, après avoir identifié le changement à appliquer.
Dans les déploiements, des tags d’image explicites rendent les mises à jour plus prévisibles que latest. La maîtrise de la pile repose autant sur la traçabilité des versions que sur la rapidité du démarrage.
À retenir sur docker-compose et Docker Compose
L’ancien exécutable docker-compose, écrit en Python, a été remplacé par la commande docker compose, intégrée au CLI Docker. Cette évolution ne rend pas le fichier Compose obsolète : les configurations YAML restent au cœur de l’orchestration locale de plusieurs conteneurs.
La clé version, présente dans d’anciens exemples, n’est plus nécessaire dans les fichiers utilisant la spécification Compose actuelle. Pour un projet durable, versionnez la configuration, externalisez les secrets et documentez les commandes qui modifient les données.
Questions fréquentes sur Docker Compose up
Comment démarrer les conteneurs avec Docker Compose ?
Dans le répertoire du fichier Compose, exécutez docker compose up. Ajoutez -d pour lancer les services en arrière-plan, ou –build -d pour reconstruire les images avant leur démarrage.
Quelle différence entre –build et –force-recreate ?
L’option –build demande la reconstruction des images avant le démarrage. –force-recreate recrée les conteneurs même si Compose ne détecte pas de changement nécessitant cette opération. Les volumes persistants constituent un mécanisme distinct.
La commande docker compose down supprime-t-elle les données ?
Par défaut, down supprime les conteneurs et les réseaux du projet, mais conserve les volumes nommés. L’option -v supprime aussi ces volumes et peut donc effacer des données persistantes.
Comment consulter les journaux d’un service Compose ?
Utilisez docker compose logs nom_du_service pour afficher ses journaux. Ajoutez -f pour suivre leur évolution en temps réel, par exemple docker compose logs -f api.
Docker Compose est-il différent de docker-compose ?
docker compose, sans tiret, est la commande actuelle intégrée au CLI Docker. L’ancien binaire docker-compose a été déprécié en 2023 ; les fichiers Compose YAML restent utilisés.
