Docker-Netzwerk im Beispiel

Docker-Netzwerk: IP-Übersicht und Pinning-Strategie

Dieser Artikel zeigt an einem konkreten Beispiel-Setup wie die IP-Vergabe in einem Docker-Netzwerk mit mehreren Diensten funktioniert — und welche Container gepinnt werden müssen.

Er ist das praktische Gegenstück zu Webserver, Reverse Proxy und Container – wie die Schichten zusammenspielen und ergänzt die Konzepte dort um die konkrete Netzwerkkonfiguration.

---

Das Beispiel-Setup

Alle Container laufen im gemeinsamen Bridge-Netzwerk mein_netzwerk mit dem Subnetz 172.18.0.0/16, Gateway 172.18.0.1.

Die Dienste im Überblick:

Dienst	Container-Name	Aufgabe
Reverse Proxy	caddy	TLS-Terminierung, Routing, Security-Header
Cloud	nextcloud	Dateiablage, Kalender, Kontakte
Office-Editor	collabora	Dokumente im Browser bearbeiten (WOPI)
Medienwiedergabe	jellyfin	Film- und Musikbibliothek
Datenbank (Cloud)	nc-db	MariaDB für Nextcloud
Cache (Cloud)	nc-redis	Redis für Nextcloud-Sessions

---

Gepinnte IPs

Gepinnt werden müssen nur Container die als Ziel in extra_hosts eines anderen Containers erscheinen, oder auf die eine Firewall-Regel direkt zeigt.

Container	Feste IP	Grund
caddy	172.18.0.6	Ziel in extra_hosts von Nextcloud. Nextcloud muss Collabora über Caddy intern erreichen — nicht über die externe IP (Hairpinning).
nextcloud	172.18.0.20	Ziel in extra_hosts von Collabora. Außerdem prüft eine Caddy-Firewall-Regel diese IP direkt (@nextcloud remote_ip).

Konfiguriert wird das in der jeweiligen docker-compose.yml:

services:

 caddy:
   networks:
     mein_netzwerk:
       ipv4_address: 172.18.0.6

 nextcloud:
   networks:
     mein_netzwerk:
       ipv4_address: 172.18.0.20

networks:

 mein_netzwerk:
   external: true

---

Dynamische IPs

Diese Container haben keine feste IP — sie werden ausschließlich über ihren Docker-internen DNS-Namen angesprochen und dürfen dynamisch bleiben:

Container	Angesprochen als	Von wem
collabora	collabora:9980	Caddy
jellyfin	jellyfin:8096	Caddy
nc-db	nc-db:3306	Nextcloud
nc-redis	nc-redis:6379	Nextcloud

Docker's internes DNS löst den Container-Namen automatisch zur aktuellen IP auf — unabhängig davon ob sie sich nach einem Neustart geändert hat.

---

extra_hosts — die Ausnahmen

Zwei Container müssen eine Domain intern auflösen statt den Umweg über die externe IP zu nehmen (Hairpinning-Problem):

Nextcloud muss Collabora intern finden

services:

 nextcloud:
   extra_hosts:
     - "collabora.beispiel.de:172.18.0.6"

Zeigt auf Caddy (172.18.0.6), nicht direkt auf Collabora — weil Caddy der TLS-Terminator ist und alle Anfragen über ihn laufen.

Collabora muss Nextcloud intern finden

services:

 collabora:
   extra_hosts:
     - "nextcloud.beispiel.de:172.18.0.20"

Zeigt direkt auf Nextcloud (172.18.0.20) damit WOPI-Anfragen intern bleiben statt den Umweg über den Router zu nehmen.

---

Die Faustregel

Wer in einem extra_hosts-Eintrag als IP steht → muss gepinnt sein.

Wer nur über seinen Container-Namen angesprochen wird → darf dynamisch bleiben.

Das Zusammenspiel lässt sich so zusammenfassen:

Browser
  └─→ Caddy (172.18.0.6, gepinnt)
        ├─→ collabora:9980   (dynamisch, via Docker-DNS)
        ├─→ nextcloud:443    (dynamisch, via Docker-DNS)
        └─→ jellyfin:8096    (dynamisch, via Docker-DNS)

Collabora
  └─→ nextcloud.beispiel.de → 172.18.0.20  (via extra_hosts, gepinnt)

Nextcloud
  └─→ collabora.beispiel.de → 172.18.0.6   (via extra_hosts, gepinnt)
  └─→ nc-db:3306             (dynamisch, via Docker-DNS)
  └─→ nc-redis:6379          (dynamisch, via Docker-DNS)

---

Nach einem Neustart oder Restore prüfen

1. Welche IPs haben die Container aktuell?

docker network inspect mein_netzwerk | grep -E "Name|IPv4"

1. Löst Nextcloud Collabora intern auf?

docker exec nextcloud getent hosts collabora.beispiel.de

1. Löst Collabora Nextcloud intern auf?

docker exec collabora getent hosts nextcloud.beispiel.de </syntaxhighlight>

Beide getent-Befehle müssen interne IPs zurückgeben — nie die externe öffentliche IP. Erscheint eine externe IP, greift extra_hosts nicht und WOPI schlägt fehl.

Vollständige Checkliste: Docker-Netzwerke und Container-IPs

---

Warum getent statt nslookup?

getent hosts fragt die komplette Auflösungskette ab — inklusive /etc/hosts und extra_hosts. nslookup fragt nur DNS und ignoriert lokale Overrides vollständig.

Ein grünes nslookup bedeutet also nicht dass extra_hosts funktioniert. getent zeigt was der Container wirklich sieht.

---

Siehe auch

• Webserver, Reverse Proxy und Container – wie die Schichten zusammenspielen — die Konzepte hinter diesem Setup
• Docker-Netzwerke und Container-IPs — Pinning-Konzepte, Backup-Checkliste
• WOPI — warum extra_hosts für Collabora und Nextcloud nötig ist
• Hairpin-NAT – Collabora und Nextcloud hinter Caddy — das Grundproblem