Communityoplossing

Los ZimaOS-Dockercontainers repareren die elkaar niet kunnen vinden

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.

Als Sonarr, Radarr, Lidarr, Transmission of andere containers op ZimaOS elkaar via IP-adres kunnen bereiken, maar geen stabiele namen zoals transmission:9091, het probleem meestal te maken heeft met naamresolutie en niet met de basisconnectiviteit tussen containers. Dat onderscheid werd de belangrijkste bevinding in deze IceWhale Community-thread uit november 2025.

De standaard van Docker bridge network biedt niet op dezelfde manier automatische DNS voor containernamen als een door de gebruiker gedefinieerde bridge. In de thread kwam vervolgens een tweede, ZimaOS-specifieke complicatie aan het licht: handmatig aangemaakte bridgenetwerken konden al in Docker bestaan voordat ze correct in de ZimaOS-WebUI verschenen, en de interface kon anders geldige Docker-netwerken afwijzen vanwege vereisten voor Compose-labels.

Het belangrijkste symptoom: IP werkt, maar de containernaam niet

De oorspronkelijke gebruiker wilde dat Radarr Transmission kon bereiken via:

http://transmission:9091

De IP-adressen van containers veranderden na herstarts of updates, waardoor het vastleggen ervan onbetrouwbaar was. De containers konden elkaar via IP bereiken, maar aanroepen op basis van de hostnaam mislukten.

De verbindingstest van Radarr probeerde Transmission via de containerhostnaam in ZimaOS te bereiken
Het oorspronkelijke probleem was niet een gebrek aan IP-connectiviteit; Radarr kon Transmission niet betrouwbaar vinden via een stabiele Docker-naam.

Waarom de standaard Docker-bridge dit niet oplost

In de huidige documentatie van Docker over bridge-netwerken staat dat containers op de standaard bridge via IP met elkaar kunnen communiceren, terwijl door de gebruiker gedefinieerde bridges automatische DNS-resolutie tussen containers bieden.

“Alle apps gebruiken bridge” betekent dus niet noodzakelijk dat ze een benoemde, door de gebruiker gedefinieerde bridge met de ingebouwde DNS van Docker gebruiken.

Een door de gebruiker gedefinieerde bridge maken

sudo -i
docker network create media-net

Containers die aan dezelfde door de gebruiker gedefinieerde bridge zijn gekoppeld, kunnen elkaar normaal gesproken vinden via de containernaam of netwerkalias.

De huidige ZimaOS-documentatie gebruikt hetzelfde patroon

In de huidige ZimaSpace-documentatie wordt nu expliciet een aangepast netwerk gebruikt in de Zabbix-handleiding, omdat de standaard bridge niet het gewenste DNS-gedrag tussen containers biedt:

sudo docker network create zabbix-net

Bekijk de huidige installatiehandleiding voor ZimaOS Zabbix.

Het ZimaOS-specifieke probleem: synchronisatie van de webinterface

In de brondiscussie zorgde het aanmaken van een aangepaste bridge via Docker of Portainer er niet onmiddellijk voor dat het netwerk bruikbaar werd in de app-instellingen van ZimaOS. Gebruikers zagen fouten zoals:

network internal-network gevonden, maar heeft een onjuist label
com.docker.compose.network ingesteld op ""

Na tests met een engineer zei Zima-Giorgio dat de Docker-netwerken zelf normaal werkten, maar dat de webinterface niet synchroon kon lopen met de Docker-backend.

De door de community bevestigde stap: opnieuw opstarten nadat het netwerk is aangemaakt

sudo -i
docker network create net-a
docker network create net-b
opnieuw opstarten

Na het opnieuw opstarten verschenen de nieuw aangemaakte netwerken in het instellingenpaneel van de app. Een andere deelnemer bevestigde dat het ontbrekende opnieuw opstarten in hun test de cruciale stap was en dat naamomzetting daarna via de aangepaste bridge werkte.

ZimaOS-dashboard met aangepaste Docker-bridgenetwerken na het opnieuw opstarten van het systeem
Uit de test van de community bleek dat aangepaste netwerken in ZimaOS verschenen nadat de webinterface bij het opnieuw opstarten opnieuw met Docker was gesynchroniseerd.

Voor standaard Docker is het normaal gesproken niet nodig om de hele host opnieuw op te starten na docker network create; dit was specifiek ZimaOS-gedrag dat in de thread uit 2025 werd waargenomen.

Er bleef een compatibiliteitsprobleem met een Compose-label bestaan

Zelfs nadat het opnieuw opstarten het synchronisatieprobleem had verduidelijkt, beschreef de thread nog een andere beperking. ZimaOS kon melden dat een handmatig aangemaakt netwerk een onjuist com.docker.compose.network label.

Fout met aangepast ZimaOS-netwerk met betrekking tot het label com docker compose network
De brondiscussie maakte onderscheid tussen werkende Docker-DNS en een resterend compatibiliteitsprobleem met de ZimaOS-webinterface en Compose-metagegevens.

Zima-Giorgio zei uiteindelijk dat het niet kunnen selecteren van sommige aangemaakte netwerken een probleem leek te zijn en aan het team zou worden doorgegeven. De thread bevat geen latere bevestiging dat elk probleemgeval bij netwerkselectie was opgelost.

Controleer het netwerk met Docker, niet alleen via de gebruikersinterface

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

Test vervolgens de naamresolutie vanuit één container:

docker exec CONTAINER_A ping -c 2 CONTAINER_B

Als de image niet bevat pinggebruik een ander beschikbaar diagnoseprogramma of een tijdelijke testcontainer op hetzelfde netwerk.

Gebruik namen of aliassen in plaats van IP-adressen te wijzigen

Zodra Docker-DNS op een door de gebruiker gedefinieerde bridge werkt, configureer je applicaties met een stabiel eindpunt, zoals:

http://transmission:9091

of een netwerkalias die in Compose is gedefinieerd.

Was Cloudflared de oorzaak?

In de brondiscussie werd Cloudflared niet als hoofdoorzaak aangewezen. IP-communicatie werkte al en de fout kwam overeen met Docker-DNS- en naamresolutiegedrag.

Tijdelijke workaround: host-IP-adres en gepubliceerde poorten

De oorspronkelijke poster reserveerde tijdelijk een statisch LAN-IP-adres voor de ZimaOS-host en configureerde apps om dat IP-adres plus gepubliceerde poorten te gebruiken. Dit kan werken, maar het verkeer loopt dan via het pad van de door de host gepubliceerde poorten in plaats van via rechtstreekse routering op basis van servicenaam binnen Docker.

Checklist voor het oplossen van containernamen in ZimaOS

  1. Bevestig dat IP-naar-IP-communicatie werkt.
  2. Controleer of de containers zich op de standaardbridge of op een benoemde, door de gebruiker gedefinieerde bridge bevinden.
  3. Maak een aangepaste bridge wanneer stabiele DNS vereist is.
  4. Koppel alle vereiste services aan hetzelfde aangepaste netwerk.
  5. Op ZimaOS-versies die overeenkomen met de brondiscussie moet je opnieuw opstarten, zodat de WebUI de status van het Docker-netwerk vernieuwt.
  6. Controleer dit met docker inspect en docker network inspect.
  7. Test het oplossen van containernamen vanuit een andere container.
  8. Als ZimaOS een mismatch in Compose-labels meldt, beschouw dat dan als een UI-/integratieprobleem en niet als bewijs dat het Docker-netwerk ongeldig is.

Veelgestelde vragen over de Docker-bridge van ZimaOS

Waarom kunnen containers op de bridge elkaar niet op naam vinden?

De standaardbridge van Docker maakt IP-communicatie mogelijk, maar biedt niet automatisch DNS op basis van containernamen zoals een door de gebruiker gedefinieerde bridge dat doet.

Moet ik na docker network create opnieuw opstarten?

Standaard Docker doet dat normaal gesproken niet. In deze ZimaOS-discussie uit 2025 was een herstart nodig om de ZimaOS-WebUI de nieuwe netwerkstatus te laten ophalen.

Verstoort Cloudflared de Docker-bridge-DNS?

In de brondiscussie werd dat niet vastgesteld.

Moet ik statische Docker-IP-adressen toewijzen?

Meestal niet. Door de gebruiker gedefinieerde Docker-DNS en aliassen zijn portabeler dan hardgecodeerde container-IP-adressen.