Quelltext der Seite 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 <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>:


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:

{| 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 ===

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

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 ===

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

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 ==

# 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]]