Docker Netzwerke verstehen

Docker-Netzwerke sind mächtig, aber oft missverstanden. Hier die wichtigsten Konzepte.

Die Standard-Netzwerke

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
abc123         bridge    bridge    local
def456         host      host      local
ghi789         none      null      local

Diese drei existieren immer.

Bridge Network (Standard)

Wenn du nichts angibst, landet dein Container hier.

docker run nginx
# Nutzt das default bridge network

Problem: Container können sich nur per IP erreichen, nicht per Name.

User-Defined Bridge (Besser!)

services:
  app:
    networks:
      - backend

  db:
    networks:
      - backend

networks:
  backend:

Vorteile:

• DNS-Auflösung: app kann db per Name erreichen
• Isolation: Nur Container im gleichen Netzwerk sehen sich
• Bessere Sicherheit

# Im app-Container
ping db  # Funktioniert!

Host Network

Container nutzt das Netzwerk des Hosts direkt.

services:
  app:
    network_mode: host

Wann nutzen:

• Performance kritisch (kein NAT-Overhead)
• Container muss alle Ports nutzen
• Monitoring-Tools

Nachteile:

• Keine Port-Isolation
• Container "sieht" alle Host-Interfaces
• Nicht unter macOS/Windows (Docker Desktop)

None Network

Kein Netzwerk. Container ist komplett isoliert.

services:
  batch-job:
    network_mode: none

Für Jobs die keine Netzwerk-Kommunikation brauchen.

Mehrere Netzwerke

Ein Container kann in mehreren Netzwerken sein:

services:
  app:
    networks:
      - frontend
      - backend

  nginx:
    networks:
      - frontend

  db:
    networks:
      - backend

networks:
  frontend:
  backend:

• nginx sieht app
• app sieht nginx und db
• nginx sieht db NICHT

Das ist Microservice-Isolation.

Externe Netzwerke

Netzwerk außerhalb von Compose nutzen:

docker network create shared

services:
  app:
    networks:
      - shared

networks:
  shared:
    external: true

Gut für: Mehrere Compose-Projekte die kommunizieren müssen.

Port-Mapping verstehen

ports:
  - "8080:80"       # Host 8080 -> Container 80
  - "127.0.0.1:8080:80"  # Nur localhost
  - "80"            # Random Host-Port -> Container 80

Wichtig: 0.0.0.0:8080:80 exponiert auf ALLEN Interfaces!

Für lokale Services:

ports:
  - "127.0.0.1:5432:5432"

Container-zu-Container

Innerhalb eines Netzwerks: Nutze den Service-Namen und den Container-Port:

services:
  app:
    environment:
      - DATABASE_URL=postgres://db:5432/app
    # Nicht: localhost:5432
    # Nicht: host.docker.internal

DNS in Docker

In User-Defined Networks hat Docker einen eingebauten DNS:

# Im Container
nslookup db
# Server: 127.0.0.11 (Docker DNS)
# Address: 172.18.0.3

Debugging

Netzwerk inspizieren

docker network inspect backend

Zeigt alle Container und ihre IPs.

Connectivity testen

docker compose exec app ping db
docker compose exec app nc -zv db 5432

DNS testen

docker compose exec app nslookup db

Overlay Networks

Für Docker Swarm - Container über mehrere Hosts:

networks:
  backend:
    driver: overlay

Nur relevant für Swarm/Multi-Host.

Meine Best Practices

1. Immer User-Defined Networks - Nie das default bridge
2. Ein Netzwerk pro "Zone" - Frontend, Backend, Database
3. Interne Services ohne Ports - Nur exponieren was nötig
4. 127.0.0.1 für lokale Tools - DB nicht auf 0.0.0.0

Fazit

Docker-Netzwerke sind simpler als sie aussehen. User-Defined Bridge für 90% der Fälle, isolieren nach Bedarf.