Immich doit-il utiliser le réseau de l’hôte ou un réseau ponté ?

Pour la plupart des déploiements d’Immich basés sur Docker, un réseau bridge défini par l’utilisateur constitue le choix par défaut le plus propre ; le réseau de l’hôte est une solution ciblée, et non une amélioration universelle des performances.

Immich a principalement besoin de chemins fiables entre le client et le serveur, le serveur et la base de données, le serveur et Redis, le serveur et le service d’apprentissage automatique, ainsi qu’entre le serveur et le proxy inverse. Les deux modes réseau peuvent les fournir. Le choix doit être effectué en reproduisant le véritable problème d’échec ou d’accès, en testant un seul mode à la fois et en conservant la configuration la plus facile à observer et à rétablir.

Commencez par les chemins dont Immich a réellement besoin

Représentez la pile sous forme de connexions plutôt que de conteneurs : les clients accèdent au point de terminaison Immich public ou local ; le proxy accède au serveur Immich ; l’application accède à PostgreSQL et à Redis ; et le serveur accède au service d’apprentissage automatique. Indiquez quelles connexions restent à l’intérieur de Docker et lesquelles franchissent la limite de l’hôte.

Un bridge défini par l’utilisateur fournit aux conteneurs leur propre espace de noms réseau tout en permettant aux services du même réseau de se résoudre entre eux par leur nom de service. La présentation des modes réseau de Docker est utile pour comprendre cette distinction : les ports publiés servent aux clients de l’hôte ou externes, tandis que le DNS des conteneurs gère le trafic entre services.

Si tous les chemins requis fonctionnent déjà avec un bridge, le réseau de l’hôte n’a pas résolu de problème avéré. Conservez le bridge et documentez les noms de service, les réseaux et les ports publiés afin de pouvoir comparer ultérieurement toute modification du proxy ou de Compose à une topologie connue.

Privilégiez un bridge défini par l’utilisateur lorsque l’isolation et la stabilité des noms de service sont importantes

Le mode bridge permet aux services Immich de communiquer sur un réseau d’application explicite sans exposer chaque port de conteneur sur l’hôte. C’est particulièrement utile lorsqu’un proxy inverse partage le réseau et peut cibler directement le nom du service Immich, ce qui réduit la dépendance à une adresse IP de conteneur susceptible de changer après une recréation.

L’analyse des compromis du réseau de l’hôte dans un homelab souligne que la suppression de la traduction NAT de Docker apporte rarement un gain de performances significatif pour le trafic web ordinaire d’un homelab. Les différences les plus importantes concernent l’isolation des espaces de noms, la publication des ports et la manière dont les services se découvrent entre eux.

Le mode bridge ne constitue un mauvais choix de conception que lorsqu’un chemin requis ne peut pas être exprimé ou reste peu fiable après correction du réseau, du DNS, du pare-feu et de l’appartenance du proxy au réseau. Ne changez pas de mode simplement parce qu’un client signale que le « serveur est injoignable » : vérifiez d’abord que la requête s’arrête bien à la frontière de Docker.

Utilisez le réseau de l’hôte uniquement pour une exigence précise et reproductible

Le mode host place le conteneur dans l’espace de noms réseau de l’hôte, ce qui supprime la traduction des ports par Docker et donne au service le contexte réseau de l’hôte. Cela peut simplifier certains cas de découverte ou de routage inhabituel, mais supprime également la séparation des ports au niveau du conteneur et augmente le risque de conflits de ports sur l’hôte.

Une comparaison actuelle des réseaux bridge et host articule le choix autour des performances, de l’isolation, de l’exposition des services et du débogage. Appliquez ces critères au chemin d’Immich plutôt que de supposer que le mode host est intrinsèquement plus fiable.

Si le mode host corrige un symptôme, reproduisez le test deux fois et expliquez-en la raison. Vérifiez par exemple que le même nom d’hôte, le même compte, le même proxy et le même client échouent avec le bridge et fonctionnent avec le mode host, tandis que les journaux de l’application restent par ailleurs sains. Si le résultat ne peut pas être reproduit, le changement de mode a peut-être simplement masqué un problème de DNS ou un état réseau obsolète.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Maintenez le proxy inverse sur un itinéraire explicite et récupérable

Après le redémarrage de l’un ou l’autre conteneur, un proxy inverse doit pouvoir atteindre Immich grâce à une définition stable du serveur en amont. Avec un bridge, privilégiez un réseau défini par l’utilisateur et partagé, ainsi qu’un serveur en amont identifié par son nom de service, plutôt qu’une adresse IP de conteneur copiée manuellement. Avec le mode host, dirigez le proxy vers l’adresse et le port prévus de l’hôte, tout en vérifiant l’absence de conflits.

Le modèle de test host-versus-bridge de ZimaSpace applique une règle conditionnelle analogue : la simplicité de la découverte peut justifier le mode host, tandis que l’isolation et l’intégration explicite du proxy favorisent un bridge. Immich utilise des protocoles différents ; reprenez donc la méthode de décision plutôt que les hypothèses de ports propres à Plex.

Redémarrez d’abord le proxy seul, puis Immich seul, puis l’ensemble de la pile. Une conception fiable rétablit chaque fois les mêmes itinéraires locaux et distants sans modifier les adresses IP. Une topologie qui nécessite un recâblage manuel après une recréation n’est pas suffisamment stable, qu’elle utilise le réseau host ou bridge.

Choisissez le mode qui réussit le même test d’acceptation avec le moins de risques

Testez la connexion web locale, la connexion de l’application mobile, l’envoi d’un petit fichier, l’envoi d’un fichier volumineux, l’accès via le proxy inverse, la santé des communications entre services et un redémarrage complet. Notez la latence et les échecs, mais n’accordez pas trop d’importance à de minuscules différences de débit si les deux modes restent largement en dessous de la capacité maximale du réseau.

Choisissez le bridge lorsque toutes les fonctions réussissent et que vous bénéficiez d’une exposition explicite, du DNS des conteneurs et de l’isolation. Choisissez le mode host lorsqu’un chemin requis échoue de manière reproductible avec un bridge correctement configuré et que le mode host le corrige sans créer de conflits de ports ni élargir l’exposition au-delà de ce que vous acceptez.

Si les deux modes échouent de la même manière, cessez d’alterner les configurations réseau. La cause se trouve probablement plutôt dans le DNS, TLS, les en-têtes du proxy, l’authentification, le pare-feu, le stockage ou l’application elle-même. Conservez la requête en échec et les journaux, revenez à la topologie connue comme la plus simple et la plus fiable, puis diagnostiquez la limite suivante.