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
- Welche IPs haben die Container aktuell?
docker network inspect mein_netzwerk | grep -E "Name|IPv4"
- Löst Nextcloud Collabora intern auf?
docker exec nextcloud getent hosts collabora.beispiel.de
- 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
