Community-Lösung

ZimaOS-Docker-Container reparieren, die einander nicht auflösen können

A ZimaOS media stack could reach containers by changing IP addresses but not by stable names such as transmission. The thread identified the default Docker bridge DNS limitation, then exposed a ZimaOS WebUI synchronization and network-label issue around custom bridges.

Wenn Sonarr, Radarr, Lidarr, Transmission oder andere Container auf ZimaOS sich gegenseitig über IP-Adressen erreichen können, aber keine stabilen Namen wie transmission:9091liegt das Problem normalerweise bei der Namensauflösung und nicht bei der grundlegenden Container-Konnektivität. Diese Unterscheidung erwies sich als zentrale Erkenntnis in diesem IceWhale-Community-Thread vom November 2025.

Die standardmäßige Docker- bridge Das Netzwerk bietet nicht automatisch die DNS-Auflösung von Containernamen auf dieselbe Weise wie eine benutzerdefinierte Bridge. Im weiteren Verlauf des Threads zeigte sich außerdem eine zweite ZimaOS-spezifische Komplikation: Manuell erstellte Bridge-Netzwerke konnten in Docker vorhanden sein, bevor sie korrekt in der ZimaOS-WebUI angezeigt wurden, und die Benutzeroberfläche konnte ansonsten gültige Docker-Netzwerke aufgrund der von Compose erwarteten Labels ablehnen.

Das zentrale Symptom: IP funktioniert, aber der Containername nicht

Der ursprüngliche Nutzer wollte, dass Radarr Transmission über Folgendes erreicht:

http://transmission:9091

Die IP-Adressen der Container änderten sich nach Neustarts oder Aktualisierungen, sodass ihre feste Verwendung unzuverlässig war. Die Container konnten sich über ihre IP-Adressen erreichen, aber Verbindungen über Hostnamen schlugen fehl.

Verbindungstest von Radarr, bei dem versucht wird, Transmission über den Container-Hostnamen in ZimaOS zu erreichen
Das eigentliche Problem war nicht die fehlende IP-Konnektivität, sondern dass Radarr Transmission nicht zuverlässig über einen stabilen Docker-Namen auflösen konnte.

Warum die standardmäßige Docker-Bridge dieses Problem nicht löst

In der aktuellen Dokumentation zu Docker-Bridge-Netzwerken heißt es, dass Container im Standard-Bridge-Netzwerk über ihre IP-Adresse kommunizieren können, während benutzerdefinierte Bridges eine automatische DNS-Auflösung zwischen Containern ermöglichen.

„Alle Apps verwenden die Bridge“ bedeutet also nicht unbedingt, dass sie eine benannte benutzerdefinierte Bridge mit dem integrierten Docker-DNS verwenden.

Eine benutzerdefinierte Bridge erstellen

sudo -i
docker network create media-net

Container, die mit derselben benutzerdefinierten Bridge verbunden sind, können sich normalerweise über den Containernamen oder Netzwerkalias auflösen.

Die aktuelle ZimaOS-Dokumentation verwendet dasselbe Muster

In der aktuellen ZimaSpace-Dokumentation wird in der Zabbix-Anleitung nun ausdrücklich ein benutzerdefiniertes Netzwerk verwendet, da die Standard-Bridge nicht das gewünschte DNS-Verhalten für Container bietet:

sudo docker network create zabbix-net

Siehe die aktuelle ZimaOS-Anleitung zur Installation von Zabbix.

Das ZimaOS-spezifische Problem: WebUI-Synchronisierung

Im Quellthread wurde ein benutzerdefiniertes Bridge-Netzwerk, das über Docker oder Portainer erstellt wurde, in den App-Einstellungen von ZimaOS nicht sofort nutzbar. Nutzer sahen Fehler wie:

Das Netzwerk internal-network wurde gefunden, weist aber ein falsches Label auf
com.docker.compose.network set to ""

Nach Tests mit einem Entwickler sagte Zima-Giorgio, dass die Docker-Netzwerkfunktion selbst normal arbeitete, die WebUI jedoch möglicherweise nicht mit dem Docker-Backend synchronisiert war.

Der von der Community bestätigte Schritt: Neustart nach dem Erstellen des Netzwerks

sudo -i
docker network create net-a
docker network create net-b
Neustart

Nach dem Neustart erschienen die neu erstellten Netzwerke im Einstellungsbereich der App. Ein weiterer Teilnehmer bestätigte, dass der fehlende Neustart in seinem Test der entscheidende Schritt war und die Namensauflösung anschließend über die benutzerdefinierte Bridge funktionierte.

ZimaOS-Dashboard mit benutzerdefinierten Docker-Bridge-Netzwerken nach einem Systemneustart
Der Community-Test zeigte, dass benutzerdefinierte Netzwerke nach der erneuten Synchronisierung der ZimaOS-WebUI beim Neustart in ZimaOS erschienen.

Standard-Docker erfordert normalerweise keinen Neustart des gesamten Hosts nach docker network create; dies war ein ZimaOS-spezifisches Verhalten, das im Thread von 2025 beobachtet wurde.

Ein Kompatibilitätsproblem mit Compose-Labels blieb weiterhin bestehen

Auch nachdem der Neustart das Synchronisierungsproblem geklärt hatte, dokumentierte der Thread eine weitere Einschränkung. ZimaOS konnte melden, dass ein manuell erstelltes Netzwerk ein falsches com.docker.compose.network Label.

ZimaOS-Fehler bei benutzerdefiniertem Netzwerk im Zusammenhang mit dem Label „com.docker.compose.network“
Der Quellthread unterschied zwischen funktionierendem Docker-DNS und einem weiterhin bestehenden Kompatibilitätsproblem mit den Metadaten der ZimaOS-WebUI und von Compose.

Zima-Giorgio sagte letztlich, dass die fehlende Möglichkeit, einige erstellte Netzwerke auszuwählen, offenbar ein Problem sei und an das Team weitergeleitet werde. Der Thread enthält keine spätere Bestätigung, dass jeder Sonderfall bei der Netzwerkauswahl behoben wurde.

Netzwerk in Docker überprüfen, nicht nur in der Benutzeroberfläche

docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_B

nicht enthält, teste anschließend die Namensauflösung von einem Container aus:

docker exec CONTAINER_A ping -c 2 CONTAINER_B

Wenn das Image ping, verwende ein anderes verfügbares Diagnosetool oder einen temporären Testcontainer im selben Netzwerk.

Namen oder Aliase verwenden, anstatt IP-Adressen zu ändern

Sobald Docker-DNS in einer benutzerdefinierten Bridge funktioniert, konfiguriere Anwendungen mit einem stabilen Endpunkt wie:

http://transmission:9091

oder ein in Compose definierter Netzwerkalias.

War Cloudflared die Ursache?

Im Quellthread wurde Cloudflared nicht als Grundursache identifiziert. Die IP-Kommunikation funktionierte bereits, und der Fehler entsprach dem DNS-/Namensauflösungsverhalten von Docker.

Vorübergehende Problemumgehung: Host-IP-Adresse und veröffentlichte Ports

Der ursprüngliche Beitragende reservierte vorübergehend eine statische LAN-IP-Adresse für den ZimaOS-Host und konfigurierte die Apps so, dass sie diese IP-Adresse zusammen mit veröffentlichten Ports verwenden. Das kann funktionieren, führt jedoch über den Pfad der vom Host veröffentlichten Ports statt über ein direktes Routing zu Docker-internen Dienstnamen.

Checkliste zur Auflösung von Containernamen in ZimaOS

  1. Bestätige, dass die Kommunikation von IP zu IP funktioniert.
  2. Prüfe, ob sich die Container in der standardmäßigen Bridge oder in einer benannten, benutzerdefinierten Bridge befinden.
  3. Erstelle eine benutzerdefinierte Bridge, wenn stabiles DNS erforderlich ist.
  4. Verbinde alle erforderlichen Dienste mit demselben benutzerdefinierten Netzwerk.
  5. Starte bei ZimaOS-Versionen, die dem Quellthread entsprechen, das System neu, damit die WebUI den Status ihres Docker-Netzwerks aktualisiert.
  6. Überprüfe dies mit docker inspect und docker network inspect.
  7. Teste die Auflösung von Containernamen innerhalb eines anderen Containers.
  8. Wenn ZimaOS eine Abweichung bei den Compose-Labels meldet, sollte dies als UI-/Integrationsproblem und nicht als Beweis dafür betrachtet werden, dass das Docker-Netzwerk ungültig ist.

FAQ zur Docker-Bridge in ZimaOS

Warum können Container in der Bridge einander nicht über den Namen auflösen?

Die standardmäßige Docker-Bridge ermöglicht IP-Kommunikation, bietet aber keine automatische DNS-Auflösung von Containernamen wie eine benutzerdefinierte Bridge.

Muss ich nach docker network create neu starten?

Standard-Docker tut das normalerweise nicht. In diesem ZimaOS-Thread von 2025 war ein Neustart erforderlich, damit die ZimaOS-WebUI den neuen Netzwerkstatus abrufen konnte.

Beeinträchtigt Cloudflared das Docker-Bridge-DNS?

Im Quellthread wurde das nicht festgestellt.

Sollte ich statische Docker-IP-Adressen vergeben?

Normalerweise nicht. Benutzerdefiniertes Docker-DNS und Aliase sind portabler als fest codierte Container-IP-Adressen.