🐳 Quand la fusion de réseaux Docker est un casse-tête et que vous avez besoin d'une communication "rapide" via les ports de l'hôte

Normalement, pour que les conteneurs communiquent entre eux, la méthode standard est de créer un réseau pont commun et d'appeler les services par leur nom (par exemple : http://app-b:8080). Cependant, il arrive parfois des situations imprévues où il est difficile de suivre cette approche conventionnelle.

Utilisez cette méthode dans les "situations délicates" suivantes

  • Quand vous communiquez avec un service installé directement sur l'hôte : Par exemple, si votre base de données ou Redis est installé directement sur le système d'exploitation de l'hôte et non dans un conteneur, rendant la fusion des réseaux impossible.
  • Quand vous craignez de modifier les configurations réseau d'un conteneur créé par d'autres : Si vous hésitez à intégrer de force votre conteneur dans une configuration réseau complexe que vous ne gérez pas, de peur de provoquer des pannes.
  • Quand vous voulez vérifier une connexion 'temporaire' pendant le développement local : Lorsque la conception du réseau n'est pas la priorité et que vous devez simplement vérifier si les requêtes atteignent un service exposé via un port de l'hôte.

Dans ces cas-là, l'astuce utile est host.docker.internal.

Communication entre conteneurs via l'hôte

La solution : Une "fenêtre sur le monde extérieur au conteneur" : host.docker.internal

À l'intérieur d'un conteneur, appeler 127.0.0.1 ne fera référence qu'à lui-même. C'est là que l'utilisation du domaine spécial host.docker.internal permet de traverser les murs du conteneur pour trouver l'adresse IP de la machine hôte.

Exemple de code Python (DRF) :

# Utilisez 'host.docker.internal' au lieu de 'localhost' pour accéder aux ports de l'hôte.
# Si App-B est lié au port 8080 de l'hôte, appelez-le comme suit.
NEXTCLOUD_URL = "http://host.docker.internal:8080"

response = requests.get(NEXTCLOUD_URL)

⚠️ Si vous êtes un utilisateur Linux, une 'configuration manuelle' est indispensable

Bien que cela fonctionne par défaut avec Docker Desktop (Mac/Windows), sur un serveur Linux pur, Docker ne configure pas ce domaine automatiquement. Vous devez explicitement déclarer que "ce domaine fait référence à l'IP de l'hôte" lors de la construction ou de l'exécution.

Exemple de configuration Docker Compose :

services:
  drf-app:
    image: my-drf-app-image
    extra_hosts:
      # Déclaration pour accéder à la passerelle de l'hôte sous le nom host.docker.internal
      - "host.docker.internal:host-gateway"

Ce n'est pas toujours la solution idéale

Encore une fois, il est important de souligner que cette méthode est plutôt un dernier recours.

  1. La meilleure approche : Créer un réseau pont commun et communiquer via les noms des conteneurs (la plus sécurisée).
  2. Raison d'utiliser cette méthode : Quand vous devez accéder à un processus lancé directement sur l'hôte, ou dans un environnement 'isolé' où il est impossible d'intégrer la structure réseau.

Considérez cette 'issue de secours', rédigée l'année dernière, comme une carte cachée à n'utiliser que lorsque les méthodes conventionnelles sont bloquées !