Moet Immich hostnetwerken of een bridgenetwerk gebruiken?

Voor de meeste op Docker gebaseerde Immich-implementaties is een door de gebruiker gedefinieerd bridge-netwerk de betere standaard; host-netwerken zijn een gerichte oplossing, geen universele prestatieverbetering.

Immich heeft vooral betrouwbare verbindingen nodig tussen client en server, server en database, server en Redis, server en machine learning, en server en reverse proxy. Beide netwerkmodi kunnen daarin voorzien. Maak de keuze door de werkelijke fout of toegangsvereiste te reproduceren, telkens één modus te testen en de configuratie te behouden die het eenvoudigst te observeren en te herstellen is.

Begin met de verbindingen die Immich daadwerkelijk nodig heeft

Breng de stack in kaart als verbindingen in plaats van containers: clients bereiken het openbare of lokale Immich-eindpunt; de proxy bereikt de Immich-server; de applicatie bereikt PostgreSQL en Redis; en de server bereikt machine learning. Noteer welke verbindingen binnen Docker blijven en welke de hostgrens overschrijden.

Een door de gebruiker gedefinieerd bridge-netwerk geeft containers hun eigen netwerknaamruimte en zorgt er tegelijk voor dat services op hetzelfde netwerk elkaar via hun servicenaam kunnen vinden. Het overzicht van Docker-netwerkmodi is nuttig voor dit onderscheid: gepubliceerde poorten bedienen host- of externe clients, terwijl container-DNS het verkeer tussen services afhandelt.

Als elk vereist verbindingstraject op een bridge-netwerk al werkt, heeft host-netwerken geen aantoonbaar probleem opgelost. Behoud het bridge-netwerk en documenteer servicenamen, netwerken en gepubliceerde poorten, zodat een latere wijziging in de proxy of Compose kan worden gecontroleerd aan de hand van een bekende topologie.

Geef de voorkeur aan een door de gebruiker gedefinieerd bridge-netwerk wanneer isolatie en stabiele servicenamen belangrijk zijn

In bridge-modus kunnen Immich-services communiceren via een expliciet applicatienetwerk zonder dat elke containerpoort op de host wordt blootgesteld. Dit is vooral nuttig wanneer een reverse proxy hetzelfde netwerk deelt en de Immich-service rechtstreeks op naam kan aanspreken. Zo wordt de afhankelijkheid van een container-IP-adres verminderd, omdat dat na opnieuw aanmaken kan veranderen.

De homelab-analyse van de afwegingen rond host-netwerken merkt op dat het verwijderen van Docker-NAT zelden een betekenisvolle prestatieverbetering oplevert voor normaal webverkeer in een homelab. De belangrijkere verschillen zijn naamruimte-isolatie, het publiceren van poorten en de manier waarop services elkaar vinden.

Bridge-modus is pas een gebrekkig ontwerp wanneer een vereist verbindingstraject niet kan worden gerealiseerd of onbetrouwbaar blijft nadat netwerk, DNS, firewall en proxy-lidmaatschap zijn gecorrigeerd. Schakel niet van modus alleen omdat een client “server niet bereikbaar” meldt; bewijs eerst dat het verzoek daadwerkelijk bij de Docker-grens stopt.

Gebruik host-netwerken alleen voor een specifieke, reproduceerbare vereiste

In host-modus wordt de container in de netwerknaamruimte van de host geplaatst. Daardoor verdwijnt Docker-poortvertaling en krijgt de service de netwerkcontext van de host. Dat kan bepaalde ontdekkings- of ongebruikelijke routeringsproblemen vereenvoudigen, maar het verwijdert ook de poortgrens op containerniveau en vergroot de kans op conflicten tussen hostpoorten.

Een actuele vergelijking van bridge- en host-netwerken benadert de keuze vanuit prestaties, isolatie, blootstelling van services en foutopsporing. Pas die aspecten toe op het Immich-verbindingstraject in plaats van ervan uit te gaan dat host-modus vanzelf betrouwbaarder is.

Als host-modus één symptoom oplost, herhaal de test dan tweemaal en leg uit waarom. Bevestig bijvoorbeeld dat dezelfde hostnaam, account, proxy en client op bridge-modus falen en op host-modus werken, terwijl de applicatielogs verder gezond blijven. Als het resultaat niet kan worden herhaald, heeft de moduswijziging mogelijk alleen een DNS-probleem of verouderde netwerkstatus verhuld.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Houd de reverse proxy op een expliciete, herstelbare route

Een reverse proxy moet Immich na het opnieuw starten van beide containers via een stabiele upstreamdefinitie kunnen bereiken. Gebruik op een bridge-netwerk bij voorkeur een gedeeld, door de gebruiker gedefinieerd netwerk en een upstream op basis van de servicenaam, in plaats van een handmatig gekopieerd container-IP-adres. Gebruik in host-modus het bedoelde hostadres en de bedoelde poort voor de proxy en controleer op conflicten.

Het testpatroon voor host versus bridge van ZimaSpace gebruikt een vergelijkbare voorwaardelijke regel: eenvoudiger service-ontdekking kan host-modus rechtvaardigen, terwijl isolatie en expliciete proxy-integratie in het voordeel van een bridge-netwerk spreken. Immich gebruikt andere protocollen, dus neem de beslismethode over en niet de specifieke poortveronderstellingen voor Plex.

Start eerst alleen de proxy opnieuw, daarna alleen Immich en vervolgens de volledige stack. Een goed ontwerp herstelt telkens dezelfde lokale en externe routes zonder dat IP-adressen handmatig moeten worden aangepast. Een topologie die na opnieuw aanmaken handmatig moet worden omgebouwd, is niet stabiel genoeg, ongeacht of host- of bridge-netwerken wordt gebruikt.

Kies de modus die dezelfde acceptatietest met het minste risico doorstaat

Test lokaal inloggen via het web, verbinding met de mobiele app, een kleine upload, een grote upload, toegang via de reverse proxy, de gezondheid van verbindingen tussen services en één volledige herstart. Leg latentie en fouten vast, maar geef kleine verschillen in doorvoersnelheid niet te veel gewicht als beide modi ruim onder de netwerkcapaciteit blijven.

Kies bridge-modus wanneer alle functies werken en je baat hebt bij expliciete blootstelling, container-DNS en isolatie. Kies host-modus wanneer een vereist verbindingstraject aantoonbaar faalt op een correct geconfigureerd bridge-netwerk en host-modus dit oplost zonder poortconflicten te veroorzaken of de blootstelling verder te vergroten dan je accepteert.

Als beide modi op dezelfde manier falen, stop dan met het wisselen van netwerkmodus. De oorzaak ligt waarschijnlijker in DNS, TLS, proxyheaders, authenticatie, firewalling, opslag of de applicatie zelf. Bewaar het mislukte verzoek en de logs, keer terug naar de eenvoudigste bekende werkende topologie en onderzoek de volgende grens.