12 - Networking Docker avance

Ce que tu vas apprendre

• Creer des réseaux custom pour isoler les services
• Empecher le frontend de parler directement a la base de donnees
• Attacher un service a plusieurs réseaux
• Les overlay networks pour le multi-host
• Mettre un reverse proxy devant tes services avec Traefik
• Les commandes docker network pour debugger

Prerequisites

• Avoir compris les bases du networking Docker
• Connaitre le fonctionnement de Docker Compose

Le réseau par défaut de Compose met tous tes services dans le meme sac. Ton frontend peut parler a ta base de donnees directement. En dev, on s'en fiche. En staging ou en prod, c'est un problème de sécurité. Les réseaux custom te donnent le contrôle.

Réseaux custom : l'isolation par design

Au lieu du réseau par défaut, tu définis tes propres réseaux :

yamlservices:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"
    networks:
      - frontend-net

  api:
    build: ./api
    networks:
      - frontend-net
      - backend-net

  db:
    image: postgres:16-alpine
    networks:
      - backend-net

networks:
  frontend-net:
  backend-net:

Résultat : frontend voit api, mais pas db. api voit les deux. db ne voit que api. Le frontend ne peut pas se connecter directement a PostgreSQL, meme par accident.

C'est un principe de moindre privilege applique au réseau. Chaque service n'a acces qu'a ce dont il a besoin.

Plusieurs réseaux par service

L'exemple précédent montre deja le pattern : api est sur deux réseaux. Il joue le rôle de pont entre le frontend et le backend.

Le DNS interne fonctionne par réseau. Sur frontend-net, api est resolvable. Sur backend-net, db est resolvable. Mais frontend ne peut pas résoudre db car ils ne partagent aucun réseau.

Sur paltemps.fr, j'ai adopte cette architecture a trois couches des que j'ai ajoute un service d'administration. L'admin n'a pas besoin de voir le cache Redis, et le frontend n'a pas besoin de toucher au serveur d'admin.

Configuration avancee des réseaux

Tu peux configurer le driver, le subnet, et d'autres options :

yamlnetworks:
  backend-net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16

  external-net:
    external: true
    name: my-shared-network

Le flag external: true référencé un réseau créé en dehors de Compose. Ca permet a des services de différents fichiers Compose de communiquer.

bashdocker network create my-shared-network

Overlay networks : le multi-host

Les réseaux bridge ne fonctionnent que sur une seule machine. Pour du multi-host (Docker Swarm ou des architectures distribuees), tu utilises les overlay networks :

yamlnetworks:
  app-overlay:
    driver: overlay
    attachable: true

En pratique, si tu utilises Docker en dev, tu n'en auras probablement jamais besoin. Les overlay networks sont pour les clusters. Kubernetes a remplace Swarm pour la plupart des cas d'usage en production. Mais c'est bon de savoir que ca existe.

Reverse proxy avec Traefik

Quand tu as plusieurs services web qui ecoutent sur le port 80, tu ne peux pas tous les exposer sur le meme port. Un reverse proxy route les requêtes vers le bon service.

Traefik s'intégré nativement avec Docker. Il decouvre les services automatiquement via les labels :

yamlservices:
  traefik:
    image: traefik:v3.0
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - proxy-net

  api:
    build: ./api
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api.rule=Host(`api.localhost`)"
      - "traefik.http.services.api.loadbalancer.server.port=3000"
    networks:
      - proxy-net
      - backend-net

  frontend:
    build: ./frontend
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.frontend.rule=Host(`app.localhost`)"
      - "traefik.http.services.frontend.loadbalancer.server.port=3000"
    networks:
      - proxy-net

networks:
  proxy-net:
  backend-net:

Avec cette config, http://api.localhost atteint l'API et http://app.localhost atteint le frontend. Pas de conflit de ports. Traefik gere aussi les certificats HTTPS avec Let's Encrypt, mais c'est hors scope ici.

Caddy est une alternative plus simple si tu n'as pas besoin de la découverte automatique :

yamlservices:
  caddy:
    image: caddy:2-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile

Commandes docker network

Pour debugger le réseau, ces commandes sont indispensables :

bash# Lister tous les reseaux
docker network ls

# Inspecter un reseau (voir les conteneurs connectes)
docker network inspect <network_name>

# Connecter un conteneur a un reseau
docker network connect <network_name> <container_name>

# Deconnecter un conteneur
docker network disconnect <network_name> <container_name>

docker network inspect est celui que j'utilise le plus. Il montre l'IP de chaque conteneur connecte, le subnet, et le driver. Quand un service ne trouve pas un autre service, c'est la que tu verifies s'ils sont bien sur le meme réseau.

Tu peux aussi tester la connectivité depuis un conteneur :

bashdocker compose exec app ping db
docker compose exec app nslookup db

Si nslookup renvoie une IP, le DNS fonctionne. Si ping timeout, c'est un problème de réseau ou de firewall.

Résumé

• Les réseaux custom isolent les services : le frontend ne voit pas la base de donnees
• Un service peut etre sur plusieurs réseaux pour servir de pont
• external: true permet de partager un réseau entre plusieurs fichiers Compose
• Traefik ou Caddy servent de reverse proxy pour router par hostname
• docker network inspect est ton meilleur ami pour debugger
• On verra comment persister les donnees avec les volumes dans le prochain article

Navigation : Precedent : 11 - Networking bases | Suivant : 13 - Volumes

Sources

• Docker network drivers par Docker
• Traefik Docker provider par Traefik Labs
• Caddy reverse proxy par Caddy