TP_Docker/TP3/exo1-networks/QUESTIONS.md

TP3 Docker Networks - Réponses aux questions

1. Différences entre les types de réseaux Docker

J'ai découvert qu'il existe plusieurs types de réseaux dans Docker qui fonctionnent différemment :

Réseau Bridge :

• C'est le réseau par défaut de Docker
• Il crée un réseau privé interne où les conteneurs peuvent communiquer entre eux
• Chaque conteneur a sa propre adresse IP
• Pour accéder à un conteneur depuis ma machine, je dois utiliser l'option -p pour exposer les ports

Réseau Host :

• Dans ce mode, le conteneur utilise directement le réseau de la machine hôte
• Pas d'isolation réseau
• Les ports sont directement accessibles sans mappage
• C'est plus rapide mais moins sécurisé

Réseau None :

• Ce réseau désactive complètement toute connexion
• Le conteneur n'a pas d'interface réseau
• Il est totalement isolé
• Utile pour des traitements où la sécurité est critique

2. Pourquoi web4 est-il isolé et inaccessible ?

Le conteneur web4 est complètement isolé parce que je l'ai créé avec l'option --network none. Cela signifie que :

• Il n'a aucune interface réseau configurée
• Il n'a pas d'adresse IP
• Il ne peut ni recevoir ni envoyer de données sur le réseau
• Je ne peux pas installer ping dessus car il ne peut pas télécharger de packages
• Je ne peux pas accéder au serveur nginx qu'il contient

C'est comme si j'avais mis le conteneur dans une pièce sans portes ni fenêtres. Le serveur nginx tourne bien à l'intérieur, mais personne ne peut y accéder.

3. Analyse des résultats des tests de communication

Test entre web1 et web2 : Ces deux conteneurs peuvent communiquer facilement car ils sont sur le même réseau bridge-tp3. J'ai pu faire un ping de l'un à l'autre en utilisant simplement leur nom. C'est pratique car Docker gère la résolution de noms automatiquement dans un réseau bridge personnalisé.

Test entre web1 et web3 : Le ping ne fonctionne pas directement avec le nom "web3" car web3 est sur le réseau host et n'a pas de nom DNS dans le réseau bridge. J'ai dû utiliser l'adresse IP de ma machine hôte pour atteindre web3. C'est comme s'ils étaient sur deux réseaux différents sans passerelle directe.

Test entre web1 et web4 : Impossible de communiquer avec web4 depuis web1. Le conteneur web4 (réseau none) n'a pas d'adresse IP et est complètement isolé. C'est comme essayer d'appeler quelqu'un qui n'a pas de téléphone.

Accès HTTP depuis ma machine :

• J'ai pu accéder à web1 et web2 via les ports que j'ai exposés (8081 et 8082)
• J'ai pu accéder à web3 directement sur localhost:80 (car il utilise le réseau host)
• Impossible d'accéder à web4 (car il n'a aucune connectivité réseau)

4. Recommandations pour chaque cas d'usage

Pour un serveur web public : Je recommanderais un réseau bridge avec exposition de ports. C'est le plus adapté car :

• Je peux exposer uniquement les ports nécessaires (80/443)
• Les autres services du conteneur restent protégés
• Je peux avoir plusieurs serveurs web sur différents ports

Pour une base de données : Je choisirais un réseau bridge personnalisé sans exposition de ports. Pourquoi ?

• La base de données doit être accessible seulement par l'application
• Je ne veux pas que quelqu'un puisse y accéder depuis Internet
• Les conteneurs de mon application peuvent y accéder par nom

Pour un service de cache Redis : Je mettrais ça aussi sur un réseau bridge personnalisé, sur le même réseau que mon application. Parce que :

• Seule mon application a besoin d'accéder au cache
• C'est plus rapide si les conteneurs sont sur le même réseau
• C'est plus sécurisé de ne pas exposer Redis à l'extérieur

En conclusion, j'ai compris que le choix du réseau dépend vraiment de ce qu'on veut faire avec le conteneur et de qui doit y accéder. C'est un compromis entre accessibilité, sécurité et performance.