Docker Networking für Teams: Reverse Proxy, Subdomains und lokale Zertifikate

1. Docker Networking: Grundlagen und Netzwerk-Typen

Docker Networking ist das System, das bestimmt, wie Container miteinander und mit der Außenwelt kommunizieren. Docker erstellt bei der Installation automatisch drei Standard-Netzwerke: bridge, host und none. Das Docker Networking über das Standard-Bridge-Netzwerk verbindet Container auf demselben Host miteinander, bietet aber keine Service-Discovery über Namen – Container müssen über IP-Adressen kommunizieren, die sich bei jedem Start ändern können. Das macht das Standard-Bridge-Netzwerk für alle ernsthaften Anwendungen ungeeignet.

Benutzerdefinierte Bridge-Netzwerke lösen das Problem: Container im selben benutzerdefinierten Netzwerk können sich gegenseitig über ihren Container-Namen oder Service-Namen in Docker Compose erreichen. Das ist die Basis für funktionierendes Docker Networking in Compose-Projekten. Der Host-Netzwerk-Modus verbindet den Container direkt mit dem Netzwerk des Hosts – kein Network Address Translation (NAT), keine Port-Weiterleitung, aber auch keine Isolation. Auf Linux ermöglicht das die beste Performance für Anwendungen, die viele Verbindungen verwalten, wie Reverse Proxies oder Datenbanken mit hohem Durchsatz.

Das Overlay-Netzwerk ist für Multi-Host-Umgebungen gedacht und kommt in Docker Swarm oder Kubernetes zum Einsatz. Es ermöglicht, dass Container auf verschiedenen Hosts miteinander kommunizieren, als wären sie im selben Netzwerk. Für lokale Entwicklung und einfache Produktionsumgebungen mit einem einzelnen Host ist das Bridge-Netzwerk die richtige Wahl. Das Verständnis dieser Grundlagen ist Voraussetzung für sauberes Docker Networking in der Praxis.

2. Netzwerk-Isolation zwischen Projekten

In Docker Compose erstellt jedes Projekt standardmäßig sein eigenes Netzwerk mit dem Namen <projectname>_default. Container verschiedener Projekte können sich damit nicht per Hostnamen erreichen – eine wichtige Sicherheitseigenschaft des Docker Networking. Probleme entstehen, wenn Dienste aus verschiedenen Projekten miteinander kommunizieren müssen, zum Beispiel wenn ein Monitoring-Stack Container aus mehreren Projekten beobachten soll. Die Lösung ist ein gemeinsames externes Netzwerk, das in beiden Compose-Dateien referenziert wird.

Die Netzwerk-Isolation im Docker Networking hat auch Auswirkungen auf die Sicherheit: Ein kompromittierter Container in einem Projekt kann per se nicht auf Dienste anderer Projekte zugreifen. Wer Datenbanken, Caches oder interne APIs vor versehentlichem Zugriff aus anderen Containern schützen möchte, sollte Dienste explizit nur in internen Netzwerken ohne Port-Expositionen betreiben. Die Kombination aus projektspezifischen Netzwerken für interne Kommunikation und einem gemeinsamen Reverse-Proxy-Netzwerk für externen Zugriff ist das bewährteste Muster für professionelles Docker Networking.

# Create a shared external network for the reverse proxy
docker network create proxy-network

# docker-compose.yml — project with internal and external network
services:
  web:
    image: nginx:alpine
    networks:
      - proxy-network   # shared with Traefik for external access
      - internal        # project-internal communication
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.myapp.rule=Host(`myapp.localhost`)"

  db:
    image: postgres:16
    networks:
      - internal        # NOT exposed to proxy — internal only
    environment:
      POSTGRES_PASSWORD: secret

  redis:
    image: redis:7-alpine
    networks:
      - internal        # Only accessible within this project

networks:
  proxy-network:
    external: true      # Must be created before: docker network create proxy-network
  internal:
    driver: bridge
    internal: true      # No outbound internet access — isolated

3. Service Discovery in Docker Compose

Service Discovery ist eines der praktischsten Features des Docker Networking in Compose-Projekten. Container im selben Netzwerk können sich über den Service-Namen der Compose-Datei erreichen, nicht über IP-Adressen. Das bedeutet: Ein PHP-Container verbindet sich mit db:3306 statt mit einer IP-Adresse, ein Nginx-Container leitet Anfragen an php-fpm:9000 weiter. Diese Names werden intern über einen eingebetteten DNS-Server aufgelöst, den Docker für jedes benutzerdefinierte Netzwerk bereitstellt.

Ein wichtiges Detail bei Docker Networking und Service Discovery: Wenn ein Service in einer Compose-Datei mit einem Alias versehen wird, ist er unter diesem Alias erreichbar. Das ist nützlich, wenn mehrere Projekte denselben Service-Namen verwenden, aber unter unterschiedlichen Hostnamen erreichbar sein sollen – zum Beispiel zwei Magento-Instanzen, die beide db als Service-Namen nutzen, aber in verschiedenen Projektnetzwerken laufen. Netzwerk-Aliases lösen dieses Problem elegant, ohne Container umbenennen zu müssen.

4. Port-Konflikte vermeiden

Port-Konflikte sind eines der häufigsten Probleme beim Docker Networking in Teams, die an mehreren Projekten gleichzeitig arbeiten. Wenn drei Projekte jeweils Port 80 und 443 binden wollen, schlägt der Start jedes zweiten Projekts fehl. Die naheliegende Lösung – jedes Projekt bekommt andere Ports – führt zu URLs wie localhost:8081, localhost:8082, die schwer zu merken sind und HTTPS nicht realistisch simulieren. Die eigentliche Lösung ist ein zentraler Reverse Proxy, der Port 80 und 443 hält und Anfragen basierend auf dem Hostnamen an das richtige Projekt weiterleitet.

Ohne Reverse Proxy ist die Empfehlung für Docker Networking: Service-Ports nur im internen Netzwerk exponieren, nicht auf den Host binden. In der Compose-Datei bedeutet das: Statt ports: "80:80" nur expose: "80" verwenden. Container im selben Netzwerk können den Port trotzdem erreichen, aber der Host-Port ist nicht belegt. Das verhindert Konflikte zwischen Projekten und erzwingt den Weg über den Reverse Proxy für externen Zugriff.

5. Traefik als zentraler Reverse Proxy

Traefik ist für Docker Networking im Team-Kontext die überzeugendste Lösung als Reverse Proxy. Der entscheidende Unterschied zu Nginx: Traefik erkennt neue Container automatisch über die Docker-API und konfiguriert sich selbst anhand von Container-Labels. Es ist kein Neustart, kein Reload und keine manuelle Konfigurationsänderung notwendig, wenn ein neues Projekt gestartet wird. Der Traefik-Prozess läuft permanent und wartet auf neue Container mit entsprechenden Labels im gemeinsamen Proxy-Netzwerk.

Die Konfiguration von Traefik für lokales Docker Networking ist überschaubar: Ein Compose-Stack für Traefik selbst, der am gemeinsamen Proxy-Netzwerk teilnimmt, den Docker-Socket einbindet und die Dashboard-UI auf einem internen Port exponiert. Jedes Projekt-Service erhält dann Labels, die Traefik mitteilen, unter welchem Hostnamen der Service erreichbar sein soll, ob HTTPS aktiv ist und welche Middleware angewendet werden soll. Middleware für Basis-Authentifizierung, Redirect von HTTP zu HTTPS und Rate-Limiting sind als fertige Traefik-Komponenten verfügbar.

# traefik/docker-compose.yml — central Traefik reverse proxy
services:
  traefik:
    image: traefik:v3.2
    command:
      - "--api.dashboard=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.network=proxy-network"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      # Load TLS certificates from /certs directory
      - "--providers.file.directory=/certs"
      - "--providers.file.watch=true"
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"   # Traefik dashboard
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./certs:/certs:ro
    networks:
      - proxy-network
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.dashboard.rule=Host(`traefik.localhost`)"
      - "traefik.http.routers.dashboard.service=api@internal"

networks:
  proxy-network:
    external: true

6. Lokale Subdomains mit /etc/hosts und dnsmasq

Lokale Subdomains sind der Schritt, der das Docker Networking für Teams wirklich angenehm macht: Statt localhost:8080 sind Projekte über myapp.localhost, shop.localhost oder api.localhost erreichbar. Für einfache Fälle reicht ein Eintrag in /etc/hosts: 127.0.0.1 myapp.localhost. Der Nachteil ist, dass jeder Entwickler diese Datei manuell pflegen muss und Wildcards wie *.localhost nicht unterstützt werden.

Die elegantere Lösung für Docker Networking mit Subdomains ist dnsmasq: Ein lokaler DNS-Server, der alle Anfragen an *.localhost auf 127.0.0.1 auflöst. Auf macOS kann dnsmasq über Homebrew installiert werden, auf Linux ist es in den meisten Distributionen verfügbar. Nach der Konfiguration funktionieren alle Subdomains automatisch, ohne /etc/hosts zu bearbeiten. Moderne Browser lösen *.localhost ohne dnsmasq zu 127.0.0.1 auf, aber andere Tools wie curl und viele Entwicklungs-Utilities tun das nicht – dnsmasq schließt diese Lücke.

7. Lokale HTTPS-Zertifikate mit mkcert

HTTPS in der lokalen Entwicklungsumgebung ist keine Luxus, sondern eine Notwendigkeit: Cookies mit Secure-Flag, Service Worker, WebAuthn und HTTP/2 funktionieren nur über HTTPS. Das Docker Networking im Team muss deshalb HTTPS unterstützen, und zwar mit Zertifikaten, die der Browser als vertrauenswürdig einstuft. Selbstsignierte Zertifikate erzeugen Browserwarnungen, die im Alltag ignoriert werden – bis jemand vergisst, eine Ausnahme hinzuzufügen, und sich wundert, warum die Anwendung nicht lädt.

mkcert ist das Werkzeug der Wahl für lokales HTTPS in Docker Networking-Setups. Es erstellt eine lokale Certificate Authority (CA) und installiert diese in den System-Truststore sowie in den Truststore von Chrome, Firefox und anderen Browsern. Zertifikate, die mit dieser CA ausgestellt werden, werden vom Browser ohne Warnung als vertrauenswürdig akzeptiert. Ein einziger Befehl erstellt ein Zertifikat für beliebig viele Domains und Wildcards: mkcert "*.localhost" "localhost" "127.0.0.1". Das erzeugte Zertifikat wird in Traefik eingebunden und gilt dann für alle Subdomains.

# Install mkcert (once per developer machine)
# macOS: brew install mkcert
# Linux: see https://github.com/FiloSottile/mkcert

# Install the local CA into browser/system truststores
mkcert -install

# Generate wildcard certificate for all *.localhost subdomains
mkcert -key-file ./traefik/certs/local-key.pem \
       -cert-file ./traefik/certs/local-cert.pem \
       "*.localhost" "localhost" "127.0.0.1"

# Traefik TLS configuration file (./traefik/certs/tls.yml)
# tls:
#   certificates:
#     - certFile: /certs/local-cert.pem
#       keyFile: /certs/local-key.pem

# Project service labels for HTTPS routing
# Add to any service in any docker-compose.yml:
# labels:
#   - "traefik.enable=true"
#   - "traefik.http.routers.myapp-secure.rule=Host(`myapp.localhost`)"
#   - "traefik.http.routers.myapp-secure.entrypoints=websecure"
#   - "traefik.http.routers.myapp-secure.tls=true"

8. Mehrere Projekte gleichzeitig mit Traefik

Das finale Ziel des professionellen Docker Networking für Teams ist das gleichzeitige Betreiben mehrerer Projekte auf demselben Entwickler-Rechner ohne Konflikte. Mit Traefik als Reverse Proxy, mkcert für HTTPS und dnsmasq für Subdomains ist das Setup: Traefik läuft permanent und verwaltet Port 80 und 443. Jedes Projekt hat seine eigene Compose-Datei, eigene Netzwerke für interne Kommunikation und nimmt am gemeinsamen Proxy-Netzwerk teil. Neue Projekte werden einfach gestartet – Traefik erkennt sie automatisch und leitet Anfragen anhand des Hostnamens weiter.

Ein wichtiger Aspekt für Teams beim Docker Networking: Die Traefik-Konfiguration und das gemeinsame Proxy-Netzwerk sollten in einem separaten Repository oder als Teil eines Team-Onboarding-Skripts gepflegt werden. Neu hinzukommende Entwickler führen ein einziges Setup-Skript aus, das Traefik startet, das Proxy-Netzwerk erstellt, mkcert installiert und die CA in den Truststore einfügt. Danach können sie jedes Projekt-Repository klonen und starten, ohne weitere Netzwerk-Konfigurationen zu kennen.

9. Networking-Ansätze im Vergleich

Die Wahl der richtigen Docker Networking-Strategie hängt von der Teamgröße, der Anzahl gleichzeitig aktiver Projekte und den Anforderungen an Produktionstreue der Entwicklungsumgebung ab. Ein Einzelentwickler mit einem Projekt kann mit direktem Port-Mapping auskommen. Ein Team mit fünf Entwicklern, das sechs Projekte aktiv entwickelt, braucht die vollständige Traefik-mkcert-dnsmasq-Infrastruktur.

Das kritische Kriterium beim Docker Networking ist die Produktionstreue: Je mehr die lokale Entwicklungsumgebung der Produktionsumgebung ähnelt, desto seltener treten Fehler auf, die lokal nicht reproduzierbar sind. HTTPS lokal zu erzwingen, denselben Reverse Proxy wie in der Produktion zu verwenden und dieselbe Netzwerk-Topologie nachzubilden sind Investitionen, die sich durch weniger Produktionsvorfälle bezahlt machen. Die Traefik-basierte Lösung für Docker Networking ist in dieser Hinsicht der direkten Port-Mapping-Variante klar überlegen.

10. Zusammenfassung

Professionelles Docker Networking für Teams löst die klassischen Probleme – Port-Konflikte, fehlende HTTPS-Unterstützung und schwer merkbare URLs – durch eine klare Infrastruktur: Traefik als permanenter zentraler Reverse Proxy mit automatischer Label-basierter Konfiguration, mkcert für vertrauenswürdige HTTPS-Zertifikate ohne Browser-Warnungen, dnsmasq für automatische Subdomain-Auflösung und sauber isolierte Projekt-Netzwerke für Sicherheit und Klarheit. Diese vier Komponenten zusammen ermöglichen, dass beliebig viele Projekte gleichzeitig laufen können.

Die wichtigste Erkenntnis beim Docker Networking ist, dass der Einrichtungsaufwand einmalig ist und sich über alle zukünftigen Projekte amortisiert. Nach dem initialen Setup startet jedes neue Projekt einfach mit docker compose up – Traefik erkennt den neuen Service automatisch, das Zertifikat gilt für alle *.localhost-Domains, und der Subdomain-Name ist über Labels frei wählbar. Das spart für jedes neue Projekt Zeit und verhindert Konfigurationsfehler durch Kopieren von Port-Nummern aus verschiedenen Compose-Dateien.

11. FAQ: Docker Networking für Teams