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.
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.
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.
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
- Bevestig dat IP-naar-IP-communicatie werkt.
- Controleer of de containers zich op de standaardbridge of op een benoemde, door de gebruiker gedefinieerde bridge bevinden.
- Maak een aangepaste bridge wanneer stabiele DNS vereist is.
- Koppel alle vereiste services aan hetzelfde aangepaste netwerk.
- Op ZimaOS-versies die overeenkomen met de brondiscussie moet je opnieuw opstarten, zodat de WebUI de status van het Docker-netwerk vernieuwt.
- Controleer dit met
docker inspectendocker network inspect. - Test het oplossen van containernamen vanuit een andere container.
- 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.
