Napraw kontenery Docker w ZimaOS, które nie mogą się wzajemnie odnaleźć

Jeśli Sonarr, Radarr, Lidarr, Transmission lub inne kontenery w ZimaOS mogą łączyć się ze sobą za pomocą adresu IP, ale nie mogą używać stabilnych nazw, takich jak transmission:9091, problemem jest zwykle rozpoznawanie nazw, a nie podstawowa łączność kontenerów. To rozróżnienie stało się kluczowym ustaleniem w tym wątku społeczności IceWhale z listopada 2025 roku.

Domyślny most Dockera bridge sieć nie zapewnia automatycznego DNS-u nazw kontenerów w taki sam sposób jak most zdefiniowany przez użytkownika. Wątek ujawnił następnie drugą komplikację specyficzną dla ZimaOS: ręcznie utworzone sieci bridge mogły istnieć w Dockerze, zanim pojawiły się poprawnie w interfejsie ZimaOS WebUI, a interfejs mógł odrzucać poprawne skądinąd sieci Dockera z powodu oczekiwanych etykiet Compose.

Kluczowy objaw: adres IP działa, ale nazwa kontenera nie

Pierwotny użytkownik chciał, aby Radarr łączył się z Transmission za pomocą:

http://transmission:9091

Adresy IP kontenerów zmieniały się po ponownym uruchomieniu lub aktualizacjach, więc ich wpisywanie na stałe było zawodne. Kontenery mogły komunikować się ze sobą za pomocą adresów IP, ale wywołania oparte na nazwach hostów kończyły się niepowodzeniem.

Dlaczego domyślny most Dockera tego nie rozwiązuje

Aktualna dokumentacja sieci bridge Dockera mówi, że kontenery w domyślnym moście mogą komunikować się za pomocą adresów IP, podczas gdy mosty zdefiniowane przez użytkownika zapewniają automatyczne rozpoznawanie DNS między kontenerami.

Zatem stwierdzenie, że „wszystkie aplikacje używają bridge”, nie musi oznaczać, że korzystają z nazwanego mostu zdefiniowanego przez użytkownika z wbudowanym DNS-em Dockera.

Utwórz most zdefiniowany przez użytkownika

sudo -i
docker network create media-net

Kontenery podłączone do tego samego mostu zdefiniowanego przez użytkownika zwykle mogą rozpoznawać się nawzajem za pomocą nazwy kontenera lub aliasu sieciowego.

Aktualna dokumentacja ZimaOS korzysta z tego samego wzorca

Aktualna dokumentacja ZimaSpace wyraźnie wykorzystuje teraz niestandardową sieć w przewodniku Zabbix, ponieważ domyślny most nie zapewnia pożądanego zachowania DNS kontenerów:

sudo docker network create zabbix-net

Zobacz aktualny przewodnik instalacji ZimaOS Zabbix.

Problem specyficzny dla ZimaOS: synchronizacja WebUI

W wątku źródłowym utworzenie niestandardowej sieci mostkowej za pomocą Dockera lub Portainera nie powodowało natychmiastowej dostępności sieci w ustawieniach aplikacji ZimaOS. Użytkownicy widzieli błędy takie jak:

stwierdzono, że sieć internal-network ma nieprawidłową etykietę
com.docker.compose.network ustawione na ""

Po testach z inżynierem Zima-Giorgio stwierdził, że sama funkcja sieciowa Dockera działała prawidłowo, ale WebUI mogło być niesynchronizowane z backendem Dockera.

Potwierdzony przez społeczność krok: uruchom ponownie system po utworzeniu sieci

sudo -i
docker network create net-a
docker network create net-b
ponowne uruchomienie

Po ponownym uruchomieniu nowo utworzone sieci pojawiły się w panelu ustawień aplikacji. Inny uczestnik potwierdził, że brak ponownego uruchomienia był kluczowym krokiem w jego teście, a rozpoznawanie nazw działało później w niestandardowej sieci mostkowej.

Standardowy Docker zwykle nie wymaga ponownego uruchomienia całego hosta po docker network create; było to zachowanie specyficzne dla ZimaOS, zaobserwowane w wątku z 2025 roku.

Nadal występował problem ze zgodnością etykiety Compose

Nawet po ponownym uruchomieniu, które wyjaśniło problem z synchronizacją, wątek dokumentował kolejne ograniczenie. ZimaOS mógł zgłaszać, że ręcznie utworzona sieć ma nieprawidłową com.docker.compose.network etykieta.

Zima-Giorgio ostatecznie stwierdził, że brak możliwości wyboru niektórych utworzonych sieci wyglądał na problem i zostanie przekazany zespołowi. W wątku nie ma późniejszego potwierdzenia, że naprawiono wszystkie przypadki brzegowe związane z wyborem sieci.

Zweryfikuj sieć w Dockerze, a nie tylko w interfejsie użytkownika

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

Następnie przetestuj rozpoznawanie nazw z jednego kontenera:

docker exec CONTAINER_A ping -c 2 CONTAINER_B

Jeśli obraz nie zawiera ping, użyj innego dostępnego narzędzia diagnostycznego lub tymczasowego kontenera testowego w tej samej sieci.

Używaj nazw lub aliasów zamiast zmieniania adresów IP

Gdy DNS Dockera działa w moście zdefiniowanym przez użytkownika, skonfiguruj aplikacje przy użyciu stabilnego punktu końcowego, takiego jak:

http://transmission:9091

lub alias sieci zdefiniowany w Compose.

Czy Cloudflared był przyczyną?

Wątek źródłowy nie wskazał Cloudflared jako głównej przyczyny. Komunikacja za pomocą adresów IP już działała, a awaria odpowiadała zachowaniu DNS i rozpoznawania nazw w Dockerze.

Tymczasowe obejście: adres IP hosta i opublikowane porty

Autor oryginalnego wpisu tymczasowo zarezerwował statyczny adres IP w sieci LAN dla hosta ZimaOS i skonfigurował aplikacje tak, aby korzystały z tego adresu IP oraz opublikowanych portów. To może działać, ale połączenie przebiega przez ścieżkę opublikowanych portów hosta, a nie przez wewnętrzne dla Dockera routowanie oparte na nazwach usług.

Lista kontrolna rozpoznawania nazw kontenerów w ZimaOS

1. Potwierdź, że komunikacja między adresami IP działa.
2. Sprawdź, czy kontenery znajdują się w domyślnym moście, czy w nazwanym moście zdefiniowanym przez użytkownika.
3. Utwórz niestandardowy most, gdy wymagany jest stabilny DNS.
4. Podłącz wszystkie wymagane usługi do tej samej niestandardowej sieci.
5. W wersjach ZimaOS odpowiadających wersjom z wątku źródłowego uruchom ponownie system, aby WebUI odświeżył stan sieci Dockera.
6. Zweryfikuj za pomocą docker inspect oraz docker network inspect.
7. Przetestuj rozpoznawanie nazw kontenerów z poziomu innego kontenera.
8. Jeśli ZimaOS zgłasza niezgodność etykiety Compose, potraktuj to jako problem interfejsu użytkownika/integracji, a nie dowód, że sieć Dockera jest nieprawidłowa.

Często zadawane pytania dotyczące mostu kontenerów ZimaOS

Dlaczego kontenery w moście nie mogą rozpoznawać się nawzajem po nazwie?

Domyślny most Dockera umożliwia komunikację między adresami IP, ale nie zapewnia automatycznego rozpoznawania nazw kontenerów, tak jak most zdefiniowany przez użytkownika.

Czy po wykonaniu polecenia docker network create muszę ponownie uruchomić system?

Standardowy Docker zwykle tego nie robi. W tym wątku ZimaOS z 2025 roku konieczny był ponowny rozruch, aby WebUI ZimaOS pobrał nowy stan sieci.

Czy Cloudflared zakłóca rozpoznawanie nazw DNS w mostach Dockera?

Wątek źródłowy tego nie potwierdził.

Czy należy przypisywać statyczne adresy IP Dockera?

Zwykle nie. Zdefiniowane przez użytkownika serwery DNS Dockera i aliasy są bardziej przenośne niż adresy IP kontenerów wpisane na stałe.