Quand j’ai commencé à former mes étudiants en BTS SIO aux fondamentaux de Docker, la partie réseau était systématiquement celle qui posait le plus de difficultés. Et pour cause : la gestion du docker compose network mêle des concepts de virtualisation réseau, de routage et de sécurité qui ne sont pas toujours intuitifs. Pourtant, maîtriser ces configurations est indispensable dès que l’on dépasse le stade du conteneur unique.

Dans ce guide, je vous présente les 5 configurations réseau Docker Compose que je considère essentielles. Pour chacune, je détaille le fonctionnement, le cas d’usage concret et le fichier docker-compose.yml correspondant. Que vous prépariez votre BTS ou que vous gériez déjà des environnements de production, ces configurations couvrent la grande majorité des besoins.

Comprendre le réseau par défaut de Docker Compose

Avant de personnaliser quoi que ce soit, il faut bien comprendre ce que Docker Compose fait automatiquement. Lorsque vous lancez docker compose up, le moteur crée un réseau bridge dédié dont le nom suit le format nomduprojet_default. Tous les services déclarés dans votre fichier sont connectés à ce réseau sans aucune configuration supplémentaire.

Ce comportement par défaut offre deux avantages majeurs :

• Chaque conteneur peut joindre les autres par leur nom de service grâce au DNS interne de Docker
• Les conteneurs sont isolés du réseau de l’hôte, ce qui limite la surface d’attaque

Concrètement, si votre fichier docker-compose.yml déclare un service web et un service db, le service web peut se connecter à la base de données simplement en utilisant db:5432 comme hôte. Pas besoin d’adresse IP, pas besoin de configuration DNS externe.

services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret

Dans cet exemple, aucun bloc networks n’apparaît. Docker Compose crée pourtant un réseau bridge et y connecte les deux services. Vous pouvez le vérifier avec la commande docker network ls après le lancement. Ce réseau par défaut convient parfaitement pour le développement local, mais dès que vos besoins se complexifient, comme la gestion fine des ports, il faut passer aux configurations explicites.

Créer un réseau bridge personnalisé

Le docker compose network bridge personnalisé est la première configuration à maîtriser. Il offre les mêmes fonctionnalités que le réseau par défaut, mais avec un contrôle total sur le nommage, les options et l’attribution des services.

Pourquoi créer un réseau bridge explicite plutôt que de se reposer sur le défaut ? Trois raisons principales :

• Isolation sélective : vous choisissez quels services communiquent entre eux
• Nommage prédictible : le nom du réseau ne dépend plus du nom du répertoire
• Paramétrage IPAM : vous pouvez fixer le sous-réseau et la passerelle

Voici un exemple concret avec un réseau nommé frontend :

services:
  web:
    image: nginx:latest
    networks:
      - frontend
  api:
    image: node:20-alpine
    networks:
      - frontend

networks:
  frontend:
    driver: bridge

Le docker compose network driver par défaut est bridge, donc la ligne driver: bridge est facultative. Je la mets systématiquement dans mes fichiers de formation pour rendre le choix explicite. C’est une bonne pratique que je recommande également en contexte professionnel : elle évite toute ambiguïté quand un collègue reprend votre configuration.

Notez que les services qui ne sont pas attachés au réseau frontend ne pourront pas communiquer avec web et api. C’est exactement l’isolation recherchée, et c’est ce qui distingue un réseau personnalisé du réseau par défaut où tout communique avec tout.

Le mode host : performances maximales sans isolation

Le docker compose network host est la configuration la plus radicale. En activant network_mode: host, le conteneur utilise directement la pile réseau de la machine hôte. Plus de NAT, plus de bridge virtuel, plus d’isolation réseau.

services:
  monitoring:
    image: prometheus:latest
    network_mode: host

J’utilise cette configuration dans deux cas précis :

• Monitoring et observabilité : Prometheus, Grafana ou des agents de collecte qui ont besoin de voir toutes les interfaces réseau de l’hôte
• Applications sensibles à la latence : quand chaque milliseconde de surcoût réseau compte, comme pour certains services de streaming

Attention, un point critique que je rappelle systématiquement à mes étudiants : network_mode et networks sont mutuellement exclusifs. Vous ne pouvez pas utiliser les deux sur le même service. Si vous essayez, Docker Compose retournera une erreur. C’est un piège classique que l’on retrouve fréquemment sur les forums, notamment la question récurrente sur la compatibilité entre docker compose network_mode and networks.

Le mode host fonctionne uniquement sur Linux. Sur macOS et Windows, Docker tourne dans une machine virtuelle, ce qui annule les bénéfices de cette configuration. Gardez cela en tête si vous développez sur un poste non Linux avant de déployer sur un serveur Linux.

Réseau internal : isoler vos services sensibles

Le réseau docker compose network internal est ma configuration préférée pour la sécurité. En ajoutant internal: true à la définition d’un réseau, vous bloquez tout accès à Internet depuis les conteneurs connectés à ce réseau. Ils peuvent communiquer entre eux, mais aucun paquet ne sort vers l’extérieur.

services:
  api:
    image: node:20-alpine
    networks:
      - frontend
      - backend
  db:
    image: postgres:16
    networks:
      - backend
    environment:
      POSTGRES_PASSWORD: secret

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true

Dans cet exemple, le service db est connecté uniquement au réseau backend qui est marqué comme interne. La base de données ne peut pas accéder à Internet et n’est pas joignable depuis l’extérieur du réseau Docker. Le service api, lui, est connecté aux deux réseaux : il fait office de passerelle contrôlée entre le monde extérieur et la base de données.

Cette architecture suit le principe du moindre privilège, fondamental en cybersécurité. Quand je prépare des TP pour mes étudiants en option SISR, j’utilise systématiquement cette configuration pour leur montrer comment segmenter un réseau applicatif. C’est d’ailleurs un concept que l’on retrouve dans la configuration des firewalls professionnels comme Stormshield, transposé ici au niveau des conteneurs.

Un cas d’usage concret : si vous déployez Keycloak avec Docker pour gérer l’authentification, placer la base de données Keycloak sur un réseau interne empêche toute exfiltration de données même en cas de compromission du conteneur de base de données.

Architecturer avec plusieurs réseaux

La véritable puissance du docker-compose network apparaît quand vous combinez plusieurs réseaux pour segmenter votre architecture. C’est la configuration que j’enseigne en dernier car elle synthétise tous les concepts précédents.

Prenons un exemple complet avec trois tiers : frontend, backend et base de données.

services:
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
    networks:
      - front-tier

  api:
    image: node:20-alpine
    networks:
      - front-tier
      - back-tier

  worker:
    image: python:3.12-slim
    networks:
      - back-tier

  redis:
    image: redis:7-alpine
    networks:
      - back-tier

  postgres:
    image: postgres:16
    networks:
      - back-tier
    environment:
      POSTGRES_PASSWORD: secret

networks:
  front-tier:
    driver: bridge
  back-tier:
    driver: bridge
    internal: true

Avec cette architecture :

• nginx ne voit que le réseau front-tier et ne peut pas atteindre directement postgres ou redis
• api sert de point de passage entre les deux réseaux
• postgres et redis sont totalement isolés sur le réseau interne back-tier

Ce pattern est celui que je retrouve le plus souvent en production. Il correspond à une architecture classique en couches, où chaque tier ne communique qu’avec ses voisins directs. Si vous travaillez déjà avec le versioning de vos images Docker, ajouter cette segmentation réseau est l’étape logique suivante pour professionnaliser vos déploiements.

Pour les environnements plus complexes, vous pouvez également utiliser des réseaux externes partagés entre plusieurs fichiers Compose. Cela permet à des projets indépendants de communiquer entre eux :

networks:
  shared-network:
    external: true
    name: mon-reseau-partage

Ce réseau doit exister avant le lancement du projet. Vous le créez manuellement avec docker network create mon-reseau-partage. C’est une approche courante quand plusieurs microservices, gérés dans des dépôts distincts, doivent interagir.

Configurer IPAM, gateway et DNS

L’IPAM (IP Address Management) vous permet de contrôler finement l’adressage IP de vos réseaux Docker. Par défaut, Docker attribue automatiquement un sous-réseau dans la plage 172.16.0.0/12. En entreprise, cette plage est souvent déjà utilisée par le réseau interne, ce qui provoque des conflits d’adresses.

Voici comment fixer le sous-réseau et la docker compose network gateway :

networks:
  app-network:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 10.10.0.0/24
          gateway: 10.10.0.1

Vous pouvez même attribuer une adresse IP statique à un service particulier :

services:
  dns-server:
    image: coredns/coredns:latest
    networks:
      app-network:
        ipv4_address: 10.10.0.53

Cette possibilité est particulièrement utile pour les services DNS ou les proxys inverses qui doivent avoir une adresse prévisible. En parlant de docker compose dns, sachez que Docker intègre un serveur DNS embarqué (à l’adresse 127.0.0.11) qui résout automatiquement les noms de services. Vous pouvez cependant ajouter des serveurs DNS personnalisés au niveau du service :

services:
  web:
    image: nginx:latest
    dns:
      - 8.8.8.8
      - 1.1.1.1
    networks:
      - app-network

Je recommande cette configuration quand vos conteneurs doivent résoudre des noms de domaines internes à votre organisation, en complément du DNS Docker. Selon la documentation officielle de Docker sur le networking dans Compose, le DNS interne prend toujours la priorité pour la résolution des noms de services, même si vous ajoutez des serveurs personnalisés.

Le driver overlay pour Docker Swarm

Le docker compose network driver overlay est conçu pour les environnements multi-hôtes. Quand vos conteneurs sont répartis sur plusieurs machines physiques ou virtuelles dans un cluster Docker Swarm, le driver bridge ne suffit plus : il est limité à un seul hôte. Le driver overlay crée un réseau virtuel distribué qui encapsule les paquets entre les nœuds du cluster.

networks:
  cluster-network:
    driver: overlay
    attachable: true

L’option attachable: true permet aux conteneurs lancés hors du mode Swarm de se connecter à ce réseau. Sans cette option, seuls les services déployés via docker stack deploy peuvent l’utiliser.

En pratique, je rencontre le driver overlay dans trois contextes :

• Clusters de production avec haute disponibilité sur plusieurs serveurs
• Environnements de staging qui répliquent une architecture multi-nœuds
• Architectures microservices où chaque service tourne sur un hôte dédié

Le driver overlay ajoute une couche d’encapsulation (VXLAN) qui introduit un léger surcoût réseau. Pour la plupart des applications web classiques, ce surcoût est négligeable. Mais si vous comparez les performances réseau avec d’autres solutions de conteneurisation, comme Podman face à Docker, gardez en tête que l’overlay est spécifique à l’écosystème Docker Swarm.

Pour les architectures Kubernetes, vous utiliserez plutôt des plugins CNI (Calico, Flannel, Cilium) qui remplissent un rôle similaire. Le driver overlay reste néanmoins pertinent pour les équipes qui ne souhaitent pas migrer vers Kubernetes et préfèrent rester sur Swarm, solution plus simple à opérer pour des clusters de taille modeste.

Les erreurs fréquentes et comment les éviter

Après plusieurs années de formation et de mise en production, j’ai compilé les erreurs que je rencontre le plus souvent sur la configuration réseau Docker Compose. Voici les pièges à connaître :

1. Mélanger network_mode et networks

Comme évoqué plus haut, ces deux directives sont incompatibles sur un même service. Si vous avez besoin du mode host pour un conteneur mais aussi d’un réseau bridge pour un autre, séparez-les en deux services distincts et utilisez un mécanisme de communication alternatif (volumes partagés, socket Unix).

2. Oublier d’exposer les ports entre conteneurs

Sur un réseau bridge Docker, les conteneurs communiquent sur tous les ports entre eux sans avoir besoin de la directive ports. Cette directive sert uniquement à exposer un port vers la machine hôte. Beaucoup de débutants ajoutent ports: - "5432:5432" sur leur base de données alors qu’ils n’en ont pas besoin. Pour approfondir la gestion des ports Docker, j’ai rédigé un article dédié.

3. Ne pas nommer ses réseaux

Sans la propriété name, Docker Compose préfixe le nom du réseau avec le nom du projet. Cela peut poser problème si vous référencez ce réseau depuis un autre projet. Utilisez systématiquement :

networks:
  mon-reseau:
    name: mon-reseau-applicatif

4. Ignorer les conflits de sous-réseaux

Docker attribue automatiquement des sous-réseaux qui peuvent entrer en conflit avec votre réseau d’entreprise ou votre VPN. Selon les spécifications du fichier Compose pour les réseaux, il est recommandé de fixer manuellement le sous-réseau via IPAM dès que vous travaillez dans un environnement réseau contraint.

5. Utiliser des réseaux external sans les créer au préalable

Un réseau déclaré external: true doit exister avant le docker compose up. Sinon, Compose échoue immédiatement. Intégrez la création du réseau dans vos scripts de déploiement ou votre configuration réseau Docker Compose.

Tableau comparatif des configurations réseau

Pour vous aider à choisir la bonne configuration selon votre besoin, voici un récapitulatif des cinq approches détaillées dans cet article :

Ce tableau synthétise les principales différences. En pratique, la plupart des projets combinent bridge personnalisé et internal pour obtenir le meilleur équilibre entre connectivité et sécurité. Le mode host reste réservé à des cas très spécifiques, et l’overlay n’intervient que dans les architectures distribuées.

Si vous débutez avec Docker, je vous conseille de commencer par le docker compose network example le plus simple (bridge par défaut), puis d’ajouter progressivement des réseaux personnalisés à mesure que votre architecture se complexifie. C’est l’approche que je suis dans ma formation Docker, et elle fonctionne très bien pour construire une compréhension solide pas à pas.

Lucie Moreau

Formatrice IT indépendante depuis 2016, ancienne étudiante BTS SIO SLAM. 6 ans d'expérience en entreprise.