Docker Networking einfach erklärt – Bridge, Host, Macvlan

Docker macht es leicht, Apps zu starten. Spätestens beim Zugriff übers Netz tauchen Fragen auf: Wie sprechen Container miteinander. Wie kommt Traffic von außen rein. Welches Netzwerk passt zu welchem Szenario. Genau darum geht es hier.

In diesem Leitfaden lernst du praxisnah die drei wichtigsten Docker-Netzwerkmodi kennen: Bridge, Host und Macvlan. Du verstehst, wie sie funktionieren, wann du welchen Modus wählst und wie du sie korrekt konfigurierst, damit deine Services stabil, sicher und vorhersehbar laufen.

Grundlagen: Wie Docker Netzwerke denkt

Ein Docker Netzwerk verbindet Container untereinander und optional mit dem Host und dem LAN. Jeder Modus regelt IP-Vergabe, NAT/Weiterleitung, Portfreigaben und Namensauflösung unterschiedlich. Wichtig für dich sind drei Bausteine: Netzwerk-Treiber, Ports und der eingebaute DNS unter 127.0.0.11, der Container-Namen innerhalb eines benutzerdefinierten Bridge-Netzes auflöst.

Bridge – das Standardnetz für die meisten Fälle

Was Bridge tut

Beim Bridge-Modus liegen Container in einem privaten Subnetz hinter einer virtuellen Bridge. Nach außen geht es über NAT, nach innen kommunizieren Container direkt. Für externen Zugriff veröffentlichst du Ports mit -p Host:Container.

Default vs. User-Defined Bridge

Das vorinstallierte bridge-Netz funktioniert, hat aber Grenzen. Ein selbst erstelltes Bridge-Netz bietet automatische DNS-Auflösung, bessere Isolation und lesbare Namen zwischen Containern.

# eigenes Bridge-Netz erstellen
docker network create app-net

# zwei Services starten und verbinden
docker run -d --name api --network app-net myapi:latest
docker run -d --name web --network app-net -p 8080:80 myweb:latest

# web erreicht api per Name
# http://api:PORT

Wann Bridge passt

Webapps, APIs, Datenbanken auf einem Host, die du über Portfreigaben erreichbar machst. Vorteil: einfach, flexibel, sicher durch NAT. Achte darauf, nur benötigte Ports zu veröffentlichen.

Host – maximale Nähe zum Betriebssystem

Was Host tut

Beim Host-Netz nutzt ein Container direkt den Netzwerk-Stack des Hosts. Es gibt kein NAT, keine Port-Freigaben. Der Container lauscht sofort auf den Host-IPs.

# nur Linux-Hosts unterstützen --network host sinnvoll
docker run -d --network host myapp:latest

Stärken und Risiken

Vorteil: geringe Latenz, keine Port-Mappings, ideal für Netzwerktools oder hohe Paketlast.
Beachte: Isolation geringer, Port-Kollisionen mit Host-Diensten möglich, Firewall muss auf dem Host sauber greifen. Auf Docker Desktop (macOS/Windows) ist host nur eingeschränkt bzw. anders abgebildet.

Wann Host passt

Proxy, Ingress, Metrik-Sammler, Packet Capture oder Dienste, die unbedingt Original-Client-IPs ohne NAT brauchen.

Macvlan – Container mit eigener LAN-IP

Was Macvlan tut

Macvlan bindet Container direkt ins physische LAN ein. Jeder Container erhält eine eigene MAC und eigene IP aus deinem Subnetz. Von außen wirken Container wie vollwertige Geräte im gleichen L2-Netz.

# Beispiel: Parent-Interface eth0, VLAN/Netz 192.168.10.0/24
docker network create -d macvlan \
  --subnet=192.168.10.0/24 \
  --gateway=192.168.10.1 \
  -o parent=eth0 pub-net

# Container erhält eine echte LAN-IP aus dem Subnetz
docker run -d --name cam --network pub-net mycam:latest

Wichtiger Hinweis: Host-Erreichbarkeit

Standardmäßig kann der Host die Macvlan-IPs auf demselben Interface nicht direkt erreichen. Lösung: Erzeuge auf dem Host ein Macvlan-Interface im gleichen Netz und gib ihm eine freie IP.

# auf dem Host (Linux)
ip link add macvlan0 link eth0 type macvlan mode bridge
ip addr add 192.168.10.10/24 dev macvlan0
ip link set macvlan0 up

Jetzt kann der Host die Container im pub-net anpingen. In Cloud- und Desktop-Umgebungen ist Macvlan oft eingeschränkt oder nicht unterstützt.

Wann Macvlan passt

Legacy-Anwendungen, Netzwerkgeräte-Simulation, Heimnetzgeräte wie Kameras oder NAS-ähnliche Container, die im LAN sichtbar sein sollen, ohne Portumsetzungen.

Praxis: Auswahl je Szenario

Typische Webapp auf einem Host

Wähle Bridge. Nutze ein benutzerdefiniertes Netz für DNS zwischen Services und veröffentliche nur die Webports. So bleiben DB und Cache intern erreichbar, aber von außen abgeschirmt.

Netzwerknahes Tooling

Für Sniffer, Reverse Proxies oder Exporter mit hohem Durchsatz ist Host sinnvoll, solange du die Ports und Firewall sauber planst.

Appliance im LAN

Wenn der Container eine eigene IP im Heim- oder Firmennetz braucht, nimm Macvlan. Prüfe vorher Switch- und Hypervisor-Regeln und richte bei Bedarf das zusätzliche Macvlan-Interface auf dem Host ein.

Häufige Stolpersteine und Tipps

Portverwechslungen bei Bridge

Veröffentliche bewusst: -p 8080:80 heißt Host 8080 nach Container 80. Prüfe mit docker ps und teste lokal: http://localhost:8080.

DNS zwischen Containern

Der eingebaute DNS löst Service-Namen nur in selbst erstellten Bridge-Netzen auf. Nutze docker network create, dann sprechen sich Container per Name an.

Health und Startreihenfolge

Nutze Healthchecks und Restart-Policies, damit Abhängigkeiten wie DB oder Cache zuerst gesund sind, bevor Web startet.

Sicherheit

Öffne nur notwendige Ports. Für Host-Netze prüfe iptables/nftables Regeln direkt auf dem Host. Für Macvlan beachte, dass Netzwerkzugriff direkt im LAN stattfindet.

Kurzbeispiele mit Compose

Bridge mit internem DB-Zugriff

services:
  db:
    image: postgres:16
    environment:
      - POSTGRES_PASSWORD=secret
    networks: [appnet]

  web:
    image: myweb:latest
    depends_on: [db]
    ports:
      - "8080:80"
    environment:
      - DB_HOST=db
    networks: [appnet]

networks:
  appnet:
    driver: bridge

Macvlan als eigenes LAN-Interface

services:
  naslike:
    image: mynasser:latest
    networks:
      lan:
        ipv4_address: 192.168.10.20

networks:
  lan:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.10.0/24
          gateway: 192.168.10.1

Fazit

Für die meisten Setups ist Bridge die beste Standardwahl: intern sauber vernetzt, nach außen kontrolliert. Host liefert maximale Nähe zum System, wenn Performance und Original-IPs zählen, verlangt aber genaue Planung. Macvlan macht Container zu Bürgern deines LANs, ideal für Appliance-Szenarien, ist jedoch komplexer im Betrieb. Wenn du die Unterschiede kennst und bewusst wählst, wird Docker Networking vorhersehbar, sicher und angenehm zu warten.