Si Sonarr, Radarr, Lidarr, Transmission ou d’autres conteneurs sur ZimaOS peuvent communiquer entre eux par adresse IP, mais ne peuvent pas utiliser de noms stables tels que transmission:9091, le problème concerne généralement la résolution des noms plutôt que la connectivité de base entre les conteneurs. Cette distinction est devenue la principale conclusion de cette discussion de la communauté IceWhale en novembre 2025.
Le réseau par défaut de Docker bridge Le réseau ne fournit pas de DNS automatique pour les noms de conteneurs comme le fait un réseau bridge défini par l’utilisateur. La discussion a ensuite révélé une deuxième complication propre à ZimaOS : les réseaux bridge créés manuellement pouvaient exister dans Docker avant d’apparaître correctement dans l’interface Web de ZimaOS, et l’interface pouvait rejeter des réseaux Docker pourtant valides en raison des exigences liées aux libellés Compose.
Le symptôme clé : l’adresse IP fonctionne, mais le nom du conteneur échoue
L’utilisateur souhaitait initialement que Radarr atteigne Transmission à l’aide de :
http://transmission:9091Les adresses IP des conteneurs changeaient après les redémarrages ou les mises à jour, ce qui rendait leur utilisation en dur peu fiable. Les conteneurs pouvaient communiquer entre eux par adresse IP, mais les appels utilisant leur nom d’hôte échouaient.
Pourquoi le réseau bridge Docker par défaut ne résout pas le problème
La documentation actuelle de Docker sur les réseaux bridge indique que les conteneurs du réseau bridge par défaut peuvent communiquer par adresse IP, tandis que les réseaux bridge définis par l’utilisateur assurent automatiquement la résolution DNS entre les conteneurs.
Ainsi, « toutes les applications utilisent bridge » ne signifie pas nécessairement qu’elles utilisent un réseau bridge nommé et défini par l’utilisateur avec le DNS intégré de Docker.
Créer un réseau bridge défini par l’utilisateur
sudo -i
docker network create media-netLes conteneurs connectés au même réseau bridge défini par l’utilisateur peuvent généralement se résoudre mutuellement à l’aide de leur nom de conteneur ou de leur alias réseau.
La documentation actuelle de ZimaOS utilise le même modèle
La documentation actuelle de ZimaSpace utilise désormais explicitement un réseau personnalisé dans son guide Zabbix, car le réseau bridge par défaut n’offre pas le comportement DNS souhaité entre les conteneurs :
sudo docker network create zabbix-netConsultez l’guide d’installation actuel de ZimaOS Zabbix.
Le problème propre à ZimaOS : synchronisation de l’interface WebUI
Dans la discussion source, la création d’un bridge personnalisé via Docker ou Portainer ne rendait pas immédiatement le réseau utilisable depuis les paramètres de l’application ZimaOS. Les utilisateurs voyaient des erreurs telles que :
le réseau internal-network a été trouvé, mais son étiquette est incorrecte
com.docker.compose.network défini sur ""Après avoir effectué des tests avec un ingénieur, Zima-Giorgio a indiqué que le réseau Docker lui-même fonctionnait normalement, mais que l’interface WebUI pouvait être désynchronisée du backend Docker.
L’étape confirmée par la communauté : redémarrer après la création du réseau
sudo -i
docker network create net-a
docker network create net-b
redémarrageAprès le redémarrage, les réseaux nouvellement créés sont apparus dans le panneau des paramètres de l’application. Un autre participant a confirmé que l’absence de redémarrage était l’étape essentielle de son test et que la résolution des noms fonctionnait ensuite sur le bridge personnalisé.
Docker standard n’exige normalement pas le redémarrage de l’hôte entier après docker network create; il s’agissait d’un comportement propre à ZimaOS observé dans la discussion de 2025.
Un problème de compatibilité des étiquettes Compose persistait
Même après le redémarrage, qui a clarifié le problème de synchronisation, la discussion a documenté une autre limitation. ZimaOS pouvait signaler qu’un réseau créé manuellement comportait une com.docker.compose.network étiquette.
Zima-Giorgio a finalement indiqué que l’impossibilité de sélectionner certains réseaux créés semblait être un problème qui serait transmis à l’équipe. La discussion ne contient aucune confirmation ultérieure que tous les cas particuliers liés à la sélection des réseaux ont été corrigés.
Vérifier le réseau depuis Docker, et pas uniquement depuis l’interface utilisateur
docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_BTestez ensuite la résolution des noms depuis un conteneur :
docker exec CONTAINER_A ping -c 2 CONTAINER_BSi l’image n’inclut pas ping, utilisez un autre outil de diagnostic disponible ou un conteneur de test temporaire sur le même réseau.
Utilisez des noms ou des alias plutôt que de modifier les adresses IP
Une fois que le DNS Docker fonctionne sur un pont défini par l’utilisateur, configurez les applications avec un point de terminaison stable tel que :
http://transmission:9091ou un alias réseau défini dans Compose.
Cloudflared était-il à l’origine du problème ?
Le fil de discussion source n’a pas identifié Cloudflared comme la cause principale. La communication par IP fonctionnait déjà et l’échec correspondait au comportement du DNS et de la résolution des noms de Docker.
Solution de contournement temporaire : adresse IP de l’hôte et ports publiés
L’auteur du message original a temporairement réservé une adresse IP statique sur le réseau local pour l’hôte ZimaOS et configuré les applications pour utiliser cette adresse IP ainsi que les ports publiés. Cela peut fonctionner, mais le trafic passe par le chemin des ports publiés de l’hôte plutôt que par un routage interne à Docker utilisant directement les noms de service.
Liste de vérification de la résolution des noms de conteneurs dans ZimaOS
- Confirmez que la communication d’adresse IP à adresse IP fonctionne.
- Vérifiez si les conteneurs se trouvent sur le pont par défaut ou sur un pont nommé défini par l’utilisateur.
- Créez un pont personnalisé lorsqu’un DNS stable est requis.
- Connectez tous les services requis au même réseau personnalisé.
- Sur les versions de ZimaOS correspondant au fil source, redémarrez afin que l’interface Web actualise l’état de son réseau Docker.
- Vérifiez avec
docker inspectetdocker network inspect. - Testez la résolution du nom du conteneur depuis un autre conteneur.
- Si ZimaOS signale une incompatibilité d’étiquette Compose, considérez-la comme un problème d’interface ou d’intégration, et non comme la preuve que le réseau Docker est invalide.
FAQ sur le pont Docker de ZimaOS
Pourquoi les conteneurs sur le pont ne peuvent-ils pas se résoudre mutuellement par leur nom ?
Le pont par défaut de Docker autorise les communications par IP, mais ne fournit pas de DNS automatique basé sur le nom des conteneurs comme le fait un pont défini par l’utilisateur.
Dois-je redémarrer après docker network create ?
Le Docker standard ne le fait généralement pas. Dans ce fil ZimaOS de 2025, un redémarrage était nécessaire pour que l’interface Web de ZimaOS récupère le nouvel état du réseau.
Cloudflared perturbe-t-il le DNS du pont Docker ?
Le fil de discussion source ne l’a pas établi.
Dois-je attribuer des adresses IP Docker statiques ?
Généralement non. Les DNS et alias Docker définis par l’utilisateur sont plus portables que les adresses IP de conteneurs codées en dur.
