Volumes et réseaux en profondeur

Objectifs

À la fin de cette leçon, vous saurez :

• choisir entre volume nommé, bind mount et tmpfs ;
• sauvegarder un volume ;
• créer des réseaux explicites et isoler les services.

🔗 Pour vous rafraîchir la mémoire : commandes docker de base · le terminal et le prompt

Les trois types de montages

# Volume nommé : géré par Docker, emplacement optimal sur l'hôte
docker run -v pgdata:/var/lib/postgresql/data postgres

# Bind mount : dossier hôte MONTÉ tel quel (dev en live-reload)
docker run -v /home/cours/projet/src:/app/src mon-api

# tmpfs : mémoire uniquement, disparaît à l'arrêt (fichiers temporaires)
docker run --tmpfs /tmp:rw,size=64m mon-api

Règle : production = volumes nommés ; dev = bind mount pour le hot-reload ; jamais de bind mount de code en production (l'image doit être auto-suffisante).

Sauvegarder un volume

Le conteneur « aide » qui archive le volume vers le répertoire courant :

docker run --rm \
  -v pgdata:/source:ro \
  -v $(pwd):/sauvegarde \
  alpine tar czf /sauvegarde/pgdata-2026-08-23.tar.gz -C /source .

# Restauration symétrique :
docker run --rm \
  -v pgdata:/cible \
  -v $(pwd):/sauvegarde \
  alpine tar xzf /sauvegarde/pgdata-2026-08-23.tar.gz -C /cible

Notez ro (lecture seule) pendant la sauvegarde. Pour PostgreSQL, préférez quand même pg_dump (cohérence transactionnelle garantie) — le tar de volume se fait base ARRÊTÉE ou au risque d'un fichier incohérent.

Les réseaux explicites

Par défaut, Compose crée un réseau par projet où tous les services se parlent. En Docker pur, on les crée :

docker network create app-net

docker run -d --name db --network app-net postgres:17
docker run -d --name api --network app-net -p 3000:3000 mon-api

# test depuis api :
docker exec api sh -c "wget -qO- http://db:5432"   # le NOM résout !

Isolation fine avec Compose :

services:
  api:
    networks: [front, back]     # parle au proxy ET à la base
  postgres:
    networks: [back]            # INJOIGNABLE depuis front/Internet
networks:
  front:
  back:
    internal: true              # aucun accès sortant Internet

Ce découpage est de la défense en profondeur appliquée au réseau : la base n'a ni port publié ni route Internet. Un compromis du frontend ne permet pas d'atteindre PostgreSQL directement.

Exercice

1. Créez le scénario deux-réseaux ci-dessus ; vérifiez que api joint postgres mais qu'aucun conteneur « front » fictif n'y arrive.
2. Sauvegardez puis restaurez un volume avec la technique tar.
3. Montez votre src en bind mount et modifiez un fichier hôte : observez dans le conteneur.
4. Pourquoi internal: true est-il particulièrement adapté à la base ?

Résumé

• Volume nommé = prod ; bind = dev ; tmpfs = jetable.
• Sauvegarde de volume possible mais pg_dump reste roi pour la base.
• Réseaux séparés + internal = isolation réseau par défaut.