Admin: Admin verschob die Seite Docker-Netzwerk nach Docker-Netzwerk im Beispiel

2026-04-24T11:46:47Z

Admin verschob die Seite Docker-Netzwerk nach Docker-Netzwerk im Beispiel

← Nächstältere Version		Version vom 24. April 2026, 11:46 Uhr
(kein Unterschied)

Admin: /* Nach einem Neustart oder Restore prüfen */

2026-04-24T11:44:26Z

Nach einem Neustart oder Restore prüfen

← Nächstältere Version		Version vom 24. April 2026, 11:44 Uhr
Zeile 147:		Zeile 147:
	== Nach einem Neustart oder Restore prüfen ==		== Nach einem Neustart oder Restore prüfen ==

	~~<syntaxhighlight lang="bash">~~
	# Welche IPs haben die Container aktuell?		# Welche IPs haben die Container aktuell?
	docker network inspect mein_netzwerk \| grep -E "Name\|IPv4"		docker network inspect mein_netzwerk \| grep -E "Name\|IPv4"

Admin am 24. April 2026 um 11:44 Uhr

2026-04-24T11:44:04Z

← Nächstältere Version		Version vom 24. April 2026, 11:44 Uhr
Zeile 51:		Zeile 51:
	Konfiguriert wird das in der jeweiligen <code>docker-compose.yml</code>:		Konfiguriert wird das in der jeweiligen <code>docker-compose.yml</code>:

	~~<syntaxhighlight lang="yaml">~~
	services:		services:
	caddy:		caddy:
Zeile 66:		Zeile 66:
	mein_netzwerk:		mein_netzwerk:
	external: true		external: true
	~~</syntaxhighlight>~~

	----		----
Zeile 99:		Zeile 99:
	=== Nextcloud muss Collabora intern finden ===		=== Nextcloud muss Collabora intern finden ===

	~~<syntaxhighlight lang="yaml">~~
	services:		services:
	nextcloud:		nextcloud:
	extra_hosts:		extra_hosts:
	- "collabora.beispiel.de:172.18.0.6"		- "collabora.beispiel.de:172.18.0.6"
	~~</syntaxhighlight>~~

	Zeigt auf '''Caddy''' (<code>172.18.0.6</code>), nicht direkt auf Collabora —		Zeigt auf '''Caddy''' (<code>172.18.0.6</code>), nicht direkt auf Collabora —
Zeile 111:		Zeile 109:
	=== Collabora muss Nextcloud intern finden ===		=== Collabora muss Nextcloud intern finden ===

	~~<syntaxhighlight lang="yaml">~~
	services:		services:
	collabora:		collabora:
	extra_hosts:		extra_hosts:
	- "nextcloud.beispiel.de:172.18.0.20"		- "nextcloud.beispiel.de:172.18.0.20"
	~~</syntaxhighlight>~~

	Zeigt direkt auf Nextcloud (<code>172.18.0.20</code>) damit WOPI-Anfragen		Zeigt direkt auf Nextcloud (<code>172.18.0.20</code>) damit WOPI-Anfragen

Admin: Die Seite wurde neu angelegt: „== 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-Setu…“

2026-04-24T11:42:39Z

Die Seite wurde neu angelegt: „== 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-Setu…“

Neue Seite

== 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 <code>mein_netzwerk</code>
mit dem Subnetz <code>172.18.0.0/16</code>, Gateway <code>172.18.0.1</code>.

Die Dienste im Überblick:

{| class="wikitable"
! Dienst !! Container-Name !! Aufgabe
|-
| Reverse Proxy || <code>caddy</code> || TLS-Terminierung, Routing, Security-Header
|-
| Cloud || <code>nextcloud</code> || Dateiablage, Kalender, Kontakte
|-
| Office-Editor || <code>collabora</code> || Dokumente im Browser bearbeiten (WOPI)
|-
| Medienwiedergabe || <code>jellyfin</code> || Film- und Musikbibliothek
|-
| Datenbank (Cloud) || <code>nc-db</code> || MariaDB für Nextcloud
|-
| Cache (Cloud) || <code>nc-redis</code> || Redis für Nextcloud-Sessions
|}

----

== Gepinnte IPs ==

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

{| class="wikitable"
! Container !! Feste IP !! Grund
|-
| <code>caddy</code> || <code>172.18.0.6</code> || Ziel in <code>extra_hosts</code> von Nextcloud. Nextcloud muss Collabora über Caddy intern erreichen — nicht über die externe IP ([[Hairpin-NAT – Collabora und Nextcloud hinter Caddy|Hairpinning]]).
|-
| <code>nextcloud</code> || <code>172.18.0.20</code> || Ziel in <code>extra_hosts</code> von Collabora. Außerdem prüft eine Caddy-Firewall-Regel diese IP direkt (<code>@nextcloud remote_ip</code>).
|}

Konfiguriert wird das in der jeweiligen <code>docker-compose.yml</code>:

<syntaxhighlight lang="yaml">
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
</syntaxhighlight>

----

== Dynamische IPs ==

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

{| class="wikitable"
! Container !! Angesprochen als !! Von wem
|-
| <code>collabora</code> || <code>collabora:9980</code> || Caddy
|-
| <code>jellyfin</code> || <code>jellyfin:8096</code> || Caddy
|-
| <code>nc-db</code> || <code>nc-db:3306</code> || Nextcloud
|-
| <code>nc-redis</code> || <code>nc-redis:6379</code> || 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 ([[Hairpin-NAT – Collabora und Nextcloud hinter Caddy|Hairpinning-Problem]]):

=== Nextcloud muss Collabora intern finden ===

<syntaxhighlight lang="yaml">
services:
nextcloud:
extra_hosts:
- "collabora.beispiel.de:172.18.0.6"
</syntaxhighlight>

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

=== Collabora muss Nextcloud intern finden ===

<syntaxhighlight lang="yaml">
services:
collabora:
extra_hosts:
- "nextcloud.beispiel.de:172.18.0.20"
</syntaxhighlight>

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

----

== Die Faustregel ==

Wer in einem <code>extra_hosts</code>-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:

<pre>
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)
</pre>

----

== Nach einem Neustart oder Restore prüfen ==

<syntaxhighlight lang="bash">
# 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 <code>getent</code>-Befehle müssen interne IPs zurückgeben —
nie die externe öffentliche IP. Erscheint eine externe IP, greift
<code>extra_hosts</code> nicht und WOPI schlägt fehl.

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

----

== Warum getent statt nslookup? ==

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

Ein grünes <code>nslookup</code> bedeutet also nicht dass <code>extra_hosts</code>
funktioniert. <code>getent</code> 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

[[Kategorie:Docker]]
[[Kategorie:Webserver]]

Docker-Netzwerk im Beispiel - Versionsgeschichte

Admin: Admin verschob die Seite Docker-Netzwerk nach Docker-Netzwerk im Beispiel

Admin: /* Nach einem Neustart oder Restore prüfen */

Admin am 24. April 2026 um 11:44 Uhr