🐳 Docker: Wenn Netzwerk-Merges lästig sind und Sie 'schnell' über Host-Ports kommunizieren müssen

Normalerweise ist es Standard, für die Kommunikation zwischen Containern ein gemeinsames Bridge-Netzwerk zu erstellen und sie über Servicenamen (z.B. http://app-b:8080) aufzurufen. Doch im Leben gibt es oft 'unvermeidliche Situationen', in denen man nicht nach Lehrbuch vorgehen kann.

Wenn Sie in einer solchen 'Zwickmühle' stecken, nutzen Sie diese Methode

  • Für die Kommunikation mit direkt auf dem Host installierten Diensten: Wenn Datenbanken oder Redis nicht in Containern, sondern direkt auf dem Host-Betriebssystem laufen und Netzwerke daher nicht zusammengeführt werden können.
  • Wenn Sie Angst haben, die Netzwerkeinstellungen eines fremden Containers anzupassen: Wenn Sie befürchten, dass das erzwungene Hinzufügen Ihres Containers zu einer komplexen, von Dritten verwalteten Netzwerkkonfiguration zu Problemen führen könnte.
  • Wenn Sie während der lokalen Entwicklung nur 'temporär' die Verbindung testen möchten: Wenn Netzwerkdesign zweitrangig ist und Sie zunächst prüfen müssen, ob Anfragen an einen über Host-Ports exponierten Dienst gelangen.

In solchen Fällen ist host.docker.internal ein nützlicher 'Cheatcode'.

Kommunikation zwischen Containern über den Host

Lösung: Das „Fenster zur Welt außerhalb des Containers“: host.docker.internal

Innerhalb eines Containers führt der Aufruf von 127.0.0.1 nur zu sich selbst (dem Container). Mit der speziellen Domäne host.docker.internal können Sie jedoch die Containergrenzen überwinden und die IP-Adresse des Host-Systems ermitteln.

Python (DRF) Code-Beispiel:

# Verwenden Sie 'host.docker.internal' anstelle von 'localhost', um über den Host-Port zu kommunizieren.
# Wenn App-B an Port 8080 des Hosts gebunden ist, rufen Sie es wie folgt auf:
NEXTCLOUD_URL = "http://host.docker.internal:8080"

response = requests.get(NEXTCLOUD_URL)

⚠️ Für Linux-Nutzer ist eine 'manuelle Konfiguration' unerlässlich

Während dies bei Docker Desktop (Mac/Windows) standardmäßig funktioniert, wird diese Domäne auf reinen Linux-Servern nicht automatisch von Docker erkannt. Sie müssen explizit angeben, dass „diese Domäne die Host-IP bedeutet“, entweder beim Build oder beim Ausführen.

Docker Compose Konfigurationsbeispiel:

services:
  drf-app:
    image: my-drf-app-image
    extra_hosts:
      # Deklaration, dass host.docker.internal den Host-Gateway bezeichnet
      - "host.docker.internal:host-gateway"

Das ist nicht immer die optimale Lösung

Ich betone noch einmal: Diese Methode ist eher ein letzter Ausweg.

  1. Die beste Methode: Ein gemeinsames Bridge-Netzwerk erstellen und über Containernamen kommunizieren (am sichersten).
  2. Der Grund für diese Methode: Wenn Sie auf Prozesse zugreifen müssen, die direkt auf dem Host laufen, oder wenn die Netzwerkstruktur in einer 'isolierten' Umgebung nicht zusammengeführt werden kann.

Nutzen Sie diese 'Notlösung', die ich letztes Jahr beschrieben habe, nur als Geheimwaffe, wenn der Standardweg versperrt ist!