Le déploiement local ou sur un petit cluster passe souvent par un même point : comment faire communiquer plusieurs services Docker sans se perdre dans une série de commandes manuelles ? Le fichier docker-compose.yml est la réponse pratique. Il décrit, en YAML, l’ensemble des services Docker, leurs volumes, et leurs réseaux. Comprendre la mise en réseau dans Docker Compose permet d’éviter des erreurs fréquentes — erreurs d’indentation YAML, variables codées en dur, ou attentes de disponibilité mal gérées — qui plombent autant les environnements de développement que les mises en production légères.
Ce dossier présente la configuration réseau et les options principales des réseaux Docker, illustre des exemples Docker Compose concrets et propose des tactiques pour isoler et sécuriser les liaisons réseau entre services Docker. Chaque partie propose des cas pratiques, des commandes de vérification et des conseils pour diagnostiquer vite. L’approche est pragmatique : expliquer le pourquoi, puis montrer le comment avec des scénarios réels, comme le déploiement d’une application Node.js avec PostgreSQL et un reverse proxy Nginx.
- docker-compose.yml centralise la définition d’une stack multi-conteneurs et doit être versionné.
- La syntaxe YAML exige une indentation stricte à deux espaces ; les tabulations déclenchent des erreurs de parsing.
- Privilégier des tags d’images fixes (ex. postgres:16-alpine) plutôt que latest pour la stabilité.
- Utiliser des réseaux personnalisés pour l’isolation : frontend / backend / monitoring.
- Vérifier la configuration avec docker compose config avant le premier up et externaliser les secrets dans .env.
Comprendre le fichier docker-compose.yml et la mise en réseau Docker Compose
Le fichier docker-compose.yml joue le rôle de partition lisible pour toute application multi-conteneurs. Il répond à des questions simples : quels services Docker lancer ? Quels ports exposer ? Où stocker les données ? À quels réseaux connecter chaque service ?
La structure repose sur trois blocs fondamentaux : services, volumes et networks. Chacun est autonome, mais leur combinaison détermine le comportement final des conteneurs Docker. En pratique, le bloc services décrit l’image ou le build, les variables d’environnement, les montages de volumes, les ports et les directives comme depends_on ou healthcheck.
L’écriture en YAML impose des règles : indentation à deux espaces, pas de tabulation, listes initiées par un tiret suivi d’un espace, et chaînes spéciales entre guillemets si nécessaire. Une erreur d’alignement suffit souvent à faire échouer le parsing. Pour éviter les erreurs, configurer l’éditeur pour afficher les espaces invisibles et convertir automatiquement les tabulations.
Depuis 2023, l’ancien binaire docker-compose a cédé la place à la commande intégrée docker compose. La syntaxe du fichier reste la même, mais la recommandation actuelle consiste à omettre la clé version en tête de fichier. Le CLI moderne détecte les fonctionnalités utilisées et s’adapte. Avant de lancer une stack pour la première fois, exécuter docker compose config afin d’afficher la configuration résolue et de repérer les variables non définies.
Un point fréquent d’erreur concerne les variables d’environnement. Les secrets et ports ne doivent pas être codés en dur. Placer les valeurs sensibles dans un fichier .env et référencer ${NOM_VARIABLE} dans le compose garantit une meilleure hygiène. Le fichier .env doit être dans .gitignore et un .env.example partagé en dépôt sert de modèle pour les collègues.
Fil conducteur : l’entreprise fictive Atelier Lumière, petite équipe bordelaise de créatifs, a choisi Docker Compose pour uniformiser ses environnements. Le même docker-compose.yml sert pour le développement et la CI, avec un fichier override pour monter le code en bind mount en local. Cette stratégie réduit les écarts entre poste de dev et intégration continue et évite les surprises lors de la mise en production.
En pratique, la vérification rapide : placer le fichier à la racine du projet, exécuter docker compose config, lancer docker compose up -d et tester les endpoints exposés. Ce workflow suffit pour la majorité des projets locaux et des petites deployments.
Insight final : maîtriser le fichier docker-compose.yml, c’est gagner en reproductibilité ; c’est aussi la première étape pour contrôler ses réseaux Docker et prévoir une isolation adaptée.
Configurer les réseaux Docker : drivers, modes et options réseau
La notion de réseau dans Docker Compose recouvre deux idées : la connectivité logique entre services Docker et la configuration physique sous-jacente fournie par un driver réseau. Le choix du driver impacte la portée des conteneurs et leurs possibilités de communication.
Par défaut, Docker Compose crée un réseau bridge isolé pour le projet. Tous les services s’y connectent automatiquement et peuvent se joindre par nom de service. Pour des besoins plus fins, il est possible de définir des réseaux personnalisés dans la section networks du fichier compose et d’y préciser des options comme IPAM, subnet et gateway.
Voici un tableau synthétique des drivers les plus rencontrés et de leurs usages. Il aide à choisir selon que l’on reste sur un hôte unique ou que l’on distribue la charge.
| Driver | Usage typique | Avantages |
|---|---|---|
| bridge | Environnements locaux et petits déploiements | Isolation simple, DNS interne, facile à configurer |
| host | Applications à faible latence, accès direct aux interfaces réseau | Performances élevées, pas de NAT |
| overlay | Services multi-hôtes, Docker Swarm | Routage entre hôtes, sécurisé pour clusters |
| macvlan | Besoin d’adresser des conteneurs comme des machines physiques | Adresses MAC distinctes, intégration réseau héritée |
| none | Conteneurs sans réseau | Surface d’attaque réduite, usage niche |
La configuration IPAM permet de définir des plages d’adresses et d’éviter les conflits entre environnements. Pour un projet partagé sur plusieurs hôtes, attribuer des sous-réseaux dédiés évite qu’un conteneur ne se retrouve avec la même IP qu’un autre service extérieur.
Les options réseau se déclarent sous networks avec le driver choisi et éventuellement une section ipam. Par exemple, créer un réseau custom avec subnet 192.168.50.0/24 permet de contrôler précisément les affectations et la passerelle. Cette pratique est utile lorsqu’un pare-feu matériel impose des règles sur des plages définies.
Le mode network_mode offre une autre approche : mettre network_mode: host fait sortir le conteneur de l’isolation Docker et l’aligne sur la pile réseau de l’hôte. Ce mode doit être réservé aux cas où la latence ou la liaison à des ports précis est critique. Attention : il supprime l’isolation réseau entre hôte et conteneur, ce qui a des implications de sécurité.
Alias réseau et réseaux externes méritent un paragraphe : les alias permettent plusieurs points d’accès à un service au sein d’un même réseau, pratique pour migrations progressives. Les réseaux externes connectent un projet Compose à des réseaux déjà existants, utile pour intégrer des conteneurs à une infrastructure plus large.
Insight final : les options réseau servent à modeler l’architecture de communication. Penser en termes de périmètres — frontend, backend, services internes — facilite la définition de l’isolation des réseaux et des liaisons réseau souhaitées.
Pattern pratiques : isolation des réseaux, liaisons réseau et sécurité
L’isolation réseau ne se réduit pas à un mot-clé. Son objectif est d’empêcher les communications non nécessaires et de réduire la surface d’attaque. Dans Docker Compose, la règle simple consiste à connecter uniquement les services qui ont besoin de communiquer entre eux.
Un schéma fréquent : séparer Nginx (reverse proxy) et l’API sur un réseau frontend, connecter l’API et la base de données sur un réseau backend, et placer les services d’administration ou de monitoring sur un troisième réseau. Ce modèle empêche un service exposé sur Internet d’accéder directement aux données.
Liaison réseau et isolation sont liées mais distinctes. La liaison réseau décrit les routes et hôtes auxquels un service peut se connecter. L’isolation des réseaux découpe ces liaisons. Par exemple, l’API peut avoir accès à la base via le réseau backend et être accessible publiquement via Nginx qui ne traverse pas le backend directement.
Les bonnes pratiques incluent : ne pas lancer les processus en root, définir des ressources limites et utiliser des variables d’environnement pour masquer les secrets. Limiter la communication inter-services réduit les risques en cas de compromission d’un conteneur.
- Connecter uniquement ce qui doit communiquer.
- Utiliser des réseaux nommés plutôt que le réseau par défaut quand l’architecture est segmentée.
- Appliquer des politiques de redémarrage et des healthchecks pour détecter les anomalies.
Pour la gestion des accès, les alias réseau et la déclaration de réseaux externes sont utiles. Si un service tiers ou une appliance réseau doit coexister, déclarer networks: external évite de recréer un réseau qui existerait déjà sur le host. Cette méthode est pratique en production ou pour intégrer des outils de supervision centralisés.
Une remarque opérationnelle : la configuration de sécurité ne doit pas être uniquement Docker Compose. Le système hôte, les règles iptables, et les dispositifs de perimeter (reverse proxy, WAF) participent à la défense en profondeur. Docker Compose est un levier parmi d’autres.
Atelier Lumière, dans le fil conducteur, a isolé sa base de données sur un réseau back-office et réservé l’accès SSH et les outils d’administration à une machine spécifique. Cette séparation a permis de déployer des mises à jour sans exposer la base au frontend, et de reproduire la stratégie sur la CI.
Insight final : l’isolation réseau est pragmatique — réduire les liaisons réseau inutiles protège les données et simplifie le diagnostic.
Flux pratiques : gestion des volumes, healthchecks et ordre de démarrage
Les volumes et les healthchecks complètent la mise en réseau pour garantir que les services sont fiables et que les données persistent au-delà des cycles de vie des conteneurs. Sans volumes, toute donnée dans un conteneur est éphémère.
Deux types de montages sont usuels : les bind mounts et les volumes nommés. Les bind mounts relient un répertoire du poste de développement au conteneur ; ils sont pratiques pour le développement actif car ils autorisent le rechargement du code. Les volumes nommés, gérés par Docker, sont recommandés en production car ils isolent les données de l’environnement hôte et facilitent les sauvegardes.
Pour l’ordre de démarrage, depends_on indique l’ordre de création des conteneurs mais pas leur disponibilité réelle. Associer depends_on à un healthcheck avec condition: service_healthy permet de s’assurer que la cible accepte les connexions. Sans cela, l’API risque d’échouer en tentant de se connecter à une base qui n’est pas encore prête.
Un healthcheck type pour PostgreSQL utilise pg_isready. Pour une API web, un endpoint /health retournant 200 suffit souvent. Définir interval, timeout et retries permet d’ajuster la sensibilité et de réduire les faux positifs.
Quelques commandes pratiques à mémoriser : docker compose up pour démarrer, docker compose down pour arrêter et nettoyer, docker compose logs -f pour suivre les journaux. Pour exécuter des commandes ponctuelles dans un conteneur, docker compose run –rm est la méthode propre, tandis que docker compose exec permet d’entrer dans un conteneur déjà démarré.
La commande docker compose config mérite une attention particulière : elle résout les variables et affiche la configuration telle que Docker la comprend. C’est l’outil de diagnostic à lancer avant un premier up. Pour lister les conteneurs d’un projet, docker compose ps est pratique, avec l’option -a pour voir les arrêtés.
En matière de sauvegarde, monter des volumes séparés pour la base et déclarer des points d’entrée d’initialisation (init scripts) permet de restaurer ou d’initialiser des environnements reproductibles. Ajouter :ro sur les montages de configuration empêche toute modification accidentelle depuis les conteneurs.
Insight final : volumes persistants plus healthchecks fiables = démarrages robustes ; contrôler l’ordre de démarrage évite la majorité des erreurs liées aux connexions précoces.
Exemples Docker Compose : stacks, overrides et dépannage pas à pas
Pour rendre concret, voici un scénario complet autour d’Atelier Lumière. L’objectif : déployer en local une stack composée d’un reverse proxy Nginx, d’une API Node.js et d’une base PostgreSQL, avec séparation des réseaux et externalisation des secrets.
La base du projet repose sur un docker-compose.yml principal contenant la configuration commune. Un fichier docker-compose.override.yml, automatiquement chargé en développement, ajoute les bind mounts et les variables de debug. En production, un fichier spécifique docker-compose.prod.yml remplace ou surcharge les paramètres sensibles.
L’utilisation d’un .env permet de stocker DB_USER, DB_PASS, DB_NAME et APP_PORT. Ce fichier reste hors dépôt et un .env.example documente les variables nécessaires. Pour lancer la stack en développement : docker compose up –build -d ; pour la production, docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d.
- Vérifier la configuration : docker compose config.
- Construire et démarrer : docker compose up –build -d.
- Suivre les logs : docker compose logs -f api.
- Exécuter des migrations : docker compose run –rm api npm run migrate.
En cas de panne réseau entre services, commencer par docker network inspect pour voir l’état des liaisons et les adresses IP affectées. Vérifier que les services appartiennent bien aux mêmes réseaux et tester la résolution DNS interne en faisant docker compose exec api ping db. Si la résolution échoue alors que la configuration semble correcte, vérifier les noms de services et l’existence d’un réseau externe non déclaré.
Pour l’apprentissage continu, il est utile de connaître les commandes et leur usage courant. Une synthèse claire des commandes et options est disponible dans un guide pratique sur les commandes essentielles. Pour ceux qui souhaitent formaliser une formation ou rejoindre un cursus, des ressources et retours d’expérience existent sur des plateformes spécialisées, comme la présentation de l’initiative pédagogique mentionnée sur la page de formation.
Insight final : une stack bien pensée, avec overrides et .env, facilite les transitions entre dev et production et réduit le temps passé à dépanner les liaisons réseau.
Où placer le fichier docker-compose.yml ?
Le fichier docker-compose.yml se place par convention à la racine du projet. Docker Compose le recherche dans le répertoire courant. Il est possible de préciser un chemin avec -f si la configuration se trouve ailleurs.
Comment isoler le frontend et le backend dans Compose ?
Définir deux réseaux nommés, par exemple frontend et backend, puis connecter les services concernés. Le frontend et la base de données ne doivent pas être sur le même réseau si l’accès direct n’est pas souhaité.
Que fait docker compose config ?
Cette commande résout la configuration finale, remplace les variables ${…} et affiche le docker-compose tel que le CLI le comprend. Utile pour repérer les variables manquantes et erreurs de syntaxe.
Quelle différence entre bind mount et volume nommé ?
Le bind mount relie un répertoire local au conteneur, pratique en développement. Le volume nommé est géré par Docker et recommandé en production pour la persistance et la portabilité des données.