Docker-Netzwerke: Bridge, Host, DNS und Service Discovery erklärt

1. Warum Docker-Netzwerke wichtiger sind als Ports

Der erste Reflex beim Verbinden von Containern ist das Öffnen von Ports: ports: "3306:3306" und der Datenbankcontainer ist erreichbar. Das Problem: Damit ist die Datenbank auch für jeden anderen Prozess auf dem Host erreichbar, nicht nur für den Applikationscontainer. Docker-Netzwerke lösen das eleganter – Container im selben benutzerdefinierten Netzwerk können sich direkt per Service-Name erreichen, ohne Port-Forwarding auf den Host. Ports müssen nur dann geöffnet werden, wenn ein Dienst von außen erreichbar sein soll.

Wer Docker-Netzwerke richtig versteht, baut Stacks, in denen die Datenbank ausschließlich vom Applikationscontainer erreichbar ist, der Redis-Cache nur von der PHP-Anwendung gesehen wird und der Reverse Proxy als einziger Service einen Host-Port exponiert. Das ist nicht nur sicherer, sondern auch übersichtlicher: Die Netzwerktopologie in der Compose-Datei dokumentiert, welcher Dienst mit wem kommunizieren darf.

2. Bridge-Netzwerke: der Standard-Netzwerktreiber

Der Standard-Netzwerktreiber in Docker-Netzwerken ist bridge. Ein Bridge-Netzwerk erstellt eine virtuelle Netzwerkbrücke auf dem Host, an die Container angeschlossen werden. Alle Container im selben Bridge-Netzwerk können sich gegenseitig über ihre IP-Adressen erreichen. In benutzerdefinierten Bridge-Netzwerken – nicht im Standard-bridge-Netzwerk – funktioniert außerdem Name Resolution über den eingebetteten DNS-Server, sodass Container sich per Service-Name statt per IP ansprechen können.

Das Standard-bridge-Netzwerk, das Docker beim Start anlegt, hat einen wichtigen Unterschied zu benutzerdefinierten Bridge-Netzwerken: Es unterstützt kein eingebettetes DNS. Container im Standard-Bridge-Netzwerk können sich nur per IP oder über einen veralteten --link-Mechanismus verbinden. Deshalb empfiehlt die Docker-Dokumentation ausdrücklich, immer eigene Docker-Netzwerke mit dem bridge-Treiber zu erstellen, statt das Standard-Netzwerk zu verwenden. Docker Compose erledigt das automatisch.

# compose.yaml — Explicit network definitions for clean topology
networks:
  frontend:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/24
  backend:
    driver: bridge
    internal: true   # No external access — purely internal communication
  db:
    driver: bridge
    internal: true

services:
  nginx:
    image: nginx:1.27-alpine
    networks:
      - frontend      # Exposed to host via ports
      - backend       # Can reach phpfpm
    ports:
      - "80:80"
      - "443:443"

  phpfpm:
    image: php:8.4-fpm-alpine
    networks:
      - backend       # Reachable from nginx
      - db            # Can reach mysql and redis
    # No ports needed — only nginx talks to phpfpm

  mysql:
    image: mysql:8.4
    networks:
      - db            # Only phpfpm can reach mysql
    # No host port — not accessible from outside the db network

3. Eingebettetes DNS: wie Container sich per Name finden

Docker betreibt in benutzerdefinierten Docker-Netzwerken einen eingebetteten DNS-Server unter der IP 127.0.0.11. Jeder Container in einem benutzerdefinierten Netzwerk hat automatisch diesen DNS-Server als Nameserver konfiguriert. Wenn PHP-FPM einen Datenbankcontainer namens mysql per Hostname ansprechen möchte, fragt es diesen DNS-Server an, der den aktuellen Container-Namen auflöst. Das funktioniert für Service-Namen aus Compose-Dateien, Netzwerk-Aliases und Container-Namen.

Der eingebettete DNS ist dynamisch: Wenn ein Container neu startet und eine neue IP-Adresse bekommt, aktualisiert sich die DNS-Auflösung sofort. Das ist der Grund, warum Service-Namen in Datenbankverbindungsstrings in Docker-Netzwerken stabiler sind als IP-Adressen. IPs können sich bei Container-Neustarts ändern, aber der Service-Name bleibt konstant. Für Magento bedeutet das: mysql als Datenbankhost in env.php, redis als Cache-Backend und opensearch als Suchhost – ohne feste IP-Adressen.

4. Service Discovery in Docker Compose

Docker Compose implementiert Service Discovery automatisch: Jeder Service-Name in der Compose-Datei wird als DNS-Hostname im Netzwerk registriert. Wenn ein Service mehrere Replikate hat, gibt der DNS-Server alle ihre IP-Adressen zurück – Round-Robin-DNS als einfaches Load Balancing. Das ist die Grundlage dafür, dass Services sich in einem Compose-Stack per Name finden, ohne Umgebungsvariablen mit IP-Adressen zu setzen.

Für fortgeschrittene Service Discovery-Szenarien in Docker Compose bieten Netzwerk-Aliases eine Lösung: Einem Container können in einem Netzwerk mehrere Namen zugewiesen werden. Ein Migrations-Container kann unter dem Alias db-migrate erreichbar sein, während der reguläre Datenbankcontainer als mysql angesprochen wird. Sollen zwei Compose-Stacks miteinander kommunizieren, können externe Netzwerke referenziert werden – ein Stack erstellt das Netzwerk, der andere bindet es als extern ein.

# Service discovery with aliases and cross-stack networking
services:
  mysql:
    image: mysql:8.4
    networks:
      db:
        aliases:
          - database     # Reachable as both "mysql" and "database"
          - db-primary   # Useful for read/write splitting

  redis:
    image: redis:7.4-alpine
    networks:
      backend:
        aliases:
          - cache        # phpfpm can use "cache" as hostname
          - session-store

  phpfpm:
    networks:
      - backend
      - db

# Cross-stack networking: reference a network from another Compose project
networks:
  shared-proxy:
    external: true       # Created by the reverse-proxy stack
    name: proxy_default  # Exact network name from the other stack
  backend:
    driver: bridge
    internal: true
  db:
    driver: bridge
    internal: true

# Check DNS resolution inside a container
# docker exec phpfpm nslookup mysql
# docker exec phpfpm getent hosts redis

5. Host-Modus und none: wann auf den Bridge-Treiber verzichten

Neben bridge kennen Docker-Netzwerke zwei weitere wichtige Modi: host und none. Im Host-Modus teilt der Container den Netzwerk-Namespace des Hosts direkt. Es gibt keine Netzwerkisolation, keine Port-Übersetzung und keinen eingebetteten DNS. Der Container bindet direkt an die Host-Netzwerkschnittstellen. Das eliminiert den Overhead der Docker-Netzwerkbrücke und ist relevant für performancekritische Netzwerkanwendungen oder Tools, die den Host-Netzwerkstack direkt beobachten müssen.

Der none-Modus deaktiviert das Netzwerk vollständig. Der Container hat nur eine Loopback-Schnittstelle und kann keine Netzwerkverbindungen aufbauen oder annehmen. Das ist das restriktivste Isolation-Niveau in Docker-Netzwerken und sinnvoll für Batch-Processing-Container, die Dateitransformationen durchführen und keinerlei Netzwerkzugang brauchen. In Sicherheitsaudits und Compliance-Szenarien schließt none eine ganze Klasse von Angriffsvektoren aus.

6. Netzwerktrennung: Frontend, Backend und Datenbank isolieren

Die wichtigste Sicherheitsmaßnahme in Docker-Netzwerken ist die Segmentierung in mehrere Netzwerke. Ein typisches dreischichtiges Modell trennt Frontend, Backend und Datenschicht. Der Reverse Proxy (nginx, Traefik) ist im Frontend-Netzwerk und hat einen Port auf dem Host. Der Applikationsserver (PHP-FPM) ist im Frontend-Netzwerk erreichbar für den Reverse Proxy und im Backend-Netzwerk für Datenbank-Services. MySQL, Redis und OpenSearch sind ausschließlich im internen Netzwerk und nicht vom Frontend-Netzwerk aus erreichbar.

Das Flag internal: true bei einem Docker-Netzwerk verhindert, dass Container in diesem Netzwerk ausgehende Verbindungen ins Internet aufbauen können. Damit ist sichergestellt, dass eine kompromittierte Datenbankinstanz keine Daten nach außen senden kann. Für Entwicklungsumgebungen ist das weniger relevant, aber für Produktions- und Staging-Umgebungen ist es ein wichtiger Layer in einer Defense-in-Depth-Strategie. Die Netzwerkdefinition in Compose ist damit gleichzeitig eine explizite Dokumentation der erlaubten Kommunikationspfade.

# Verify network topology — which networks is a container connected to?
docker inspect phpfpm --format '{ { json .NetworkSettings.Networks } }' | jq .

# List all networks and their containers
docker network ls
docker network inspect backend --format '{ { range .Containers } }{ { .Name } } { { end } }'

# Test DNS resolution and connectivity between containers
docker exec phpfpm nslookup mysql
docker exec phpfpm curl -s http://nginx/health || true

# Check if internal network truly blocks outbound traffic
docker exec mysql curl -s --max-time 3 https://example.com || echo "Blocked — internal:true works"

# Diagnose network issues: inspect routing and iptables rules
docker exec phpfpm ip route
docker exec phpfpm cat /etc/resolv.conf   # Should show 127.0.0.11 as nameserver

7. Netzwerk-Aliases und mehrere Netzwerke pro Container

Ein Container kann in Docker-Netzwerken an mehreren Netzwerken gleichzeitig teilnehmen, jedes mit eigener IP-Adresse und eigenen Aliases. Das ermöglicht differenzierte Kommunikationsregeln: Ein API-Gateway-Container ist im öffentlichen Netzwerk unter api-gateway erreichbar, im Backend-Netzwerk unter dem Alias gateway-internal und im Monitoring-Netzwerk unter metrics-endpoint. Jedes Netzwerk hat seine eigene DNS-Auflösung, sodass ein Service unter unterschiedlichen Namen je nach Netzwerksicht erscheint.

Netzwerk-Aliases sind besonders nützlich bei Blue-Green-Deployments und bei der Migration von Diensten: Der neue Container bekommt denselben Alias wie der alte, sodass bestehende Verbindungen vom neuen Dienst bedient werden, ohne dass die Verbindungskonfiguration der abhängigen Services geändert werden muss. In Docker-Netzwerken mit mehreren Containern unter demselben Alias implementiert der eingebettete DNS automatisch DNS-Round-Robin – eine einfache Form von Load Balancing ohne zusätzliche Infrastruktur.

8. Overlay-Netzwerke für Multi-Host-Setups

Wenn Container auf verschiedenen physischen oder virtuellen Hosts miteinander kommunizieren sollen, stoßen Bridge-Docker-Netzwerke an ihre Grenzen: Sie funktionieren nur auf einem einzelnen Host. Overlay-Netzwerke erweitern das Konzept auf mehrere Hosts, indem sie VXLAN (Virtual Extensible LAN) verwenden, um Container-Netzwerkpakete über das physische Netzwerk zu tunneln. Für Docker Swarm und Docker-native Multi-Host-Setups ist der Overlay-Treiber der Standard.

Für kleinere Teams, die Docker-Netzwerke ohne Swarm nutzen, ist Overlay weniger relevant – Kubernetes oder Docker Swarm bringen eigene Netzwerkschichten mit. Wichtig zu verstehen ist jedoch das Grundprinzip: Overlay-Netzwerke ermöglichen denselben Service-Discovery-Mechanismus wie Bridge-Netzwerke, nur über Host-Grenzen hinweg. Ein Container auf Host A kann einen Container auf Host B per Service-Name ansprechen, sofern beide im selben Overlay-Netzwerk sind. Das ist die Basis dafür, dass horizontal skalierte Dienste in Swarm-Clustern wie eine einzelne Einheit erscheinen.

9. Netzwerktreiber im direkten Vergleich

Die Wahl des richtigen Netzwerktreibers hängt von Isolationsbedarf, Performance-Anforderungen und der Deployment-Topologie ab. Die folgende Tabelle fasst die wichtigsten Docker-Netzwerk-Treiber zusammen.

Für die meisten Docker-Netzwerk-Setups mit Docker Compose sind benutzerdefinierte Bridge-Netzwerke die richtige Wahl. Sie bieten DNS-basierte Service Discovery, klare Isolation und unkomplizierte Konfiguration. Host-Modus und none sind Spezialfälle, die nur dann verwendet werden sollten, wenn es einen konkreten Grund gibt. Overlay-Netzwerke kommen erst ins Spiel, wenn der Stack auf mehrere Hosts verteilt wird.

10. Zusammenfassung

Docker-Netzwerke sind die unsichtbare Schicht, die darüber entscheidet, welcher Container mit wem kommunizieren kann. Benutzerdefinierte Bridge-Netzwerke mit dem eingebetteten DNS-Server auf 127.0.0.11 ermöglichen Service Discovery per Name – ohne Port-Forwarding, ohne feste IP-Adressen. Das dreischichtige Modell aus Frontend-, Backend- und Datenbank-Netzwerk mit internal: true für die inneren Schichten schafft eine klare, dokumentierte Sicherheitsarchitektur.

Netzwerk-Aliases und mehrere Netzwerke pro Container ermöglichen flexible Kommunikationsregeln, bei denen ein Service aus verschiedenen Netzwerken unter verschiedenen Namen erreichbar ist. Für Multi-Host-Setups lösen Overlay-Netzwerke das Problem der Host-Grenzen. Das wichtigste Prinzip bei Docker-Netzwerken: So wenig Konnektivität wie möglich, so viel wie nötig – und immer benutzerdefinierte Bridge-Netzwerke statt des Legacy-Standard-Netzwerks.

11. FAQ: Docker-Netzwerke