Immich dovrebbe usare la rete host o una rete bridge?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Should Immich Use Host Networking or a Bridge Network? - Zima Store Online

Per la maggior parte delle installazioni di Immich basate su Docker, una rete bridge definita dall’utente è l’impostazione predefinita più ordinata; la rete host è una soluzione mirata, non un miglioramento universale delle prestazioni.

Immich necessita principalmente di percorsi affidabili tra client e server, server e database, server e Redis, server e apprendimento automatico, nonché server e proxy inverso. Entrambe le modalità di rete possono fornirli. La scelta dovrebbe basarsi sulla riproduzione del problema reale o del requisito di accesso, testando una modalità alla volta e mantenendo la configurazione più facile da osservare e ripristinare.

Inizia dai percorsi effettivamente necessari a Immich

Rappresenta lo stack come connessioni anziché come container: i client raggiungono l’endpoint Immich pubblico o locale; il proxy raggiunge il server Immich; l’applicazione raggiunge PostgreSQL e Redis; e il server raggiunge il servizio di apprendimento automatico. Indica quali connessioni restano all’interno di Docker e quali attraversano il confine dell’host.

Una rete bridge definita dall’utente assegna ai container il proprio spazio dei nomi di rete, consentendo al contempo ai servizi sulla stessa rete di risolversi reciprocamente tramite il nome del servizio. La panoramica del networking di Docker è utile per questa distinzione: le porte pubblicate servono i client dell’host o esterni, mentre il DNS dei container gestisce il traffico tra servizi.

Se ogni percorso necessario funziona già su una rete bridge, la rete host non ha risolto un problema dimostrato. Mantieni la rete bridge e documenta nomi dei servizi, reti e porte pubblicate, così da poter confrontare una modifica successiva al proxy o a Compose con una topologia nota.

Preferisci una rete bridge definita dall’utente quando contano isolamento e nomi dei servizi stabili

La modalità bridge consente ai servizi Immich di comunicare su una rete applicativa esplicita senza esporre sul sistema host la porta di ogni container. È particolarmente utile quando un proxy inverso condivide la rete e può indirizzare direttamente il nome del servizio Immich, riducendo la dipendenza da un indirizzo IP del container che potrebbe cambiare dopo una ricreazione.

L’analisi dell’ambiente homelab sui compromessi della rete host osserva che la rimozione del NAT di Docker raramente offre un guadagno prestazionale significativo per il normale traffico web di un homelab. Le differenze più importanti riguardano l’isolamento dello spazio dei nomi, la pubblicazione delle porte e il modo in cui i servizi si individuano reciprocamente.

La modalità bridge costituisce un problema progettuale solo quando un percorso necessario non può essere espresso o resta inaffidabile dopo aver corretto rete, DNS, firewall e appartenenza del proxy alla rete. Non cambiare modalità semplicemente perché un client segnala “server irraggiungibile”; dimostra prima che la richiesta si arresti al confine di Docker.

Usa la rete host solo per un requisito specifico e riproducibile

La modalità host colloca il container nello spazio dei nomi di rete dell’host, eliminando la traduzione delle porte di Docker e fornendo al servizio il contesto di rete dell’host. Ciò può semplificare alcuni casi di rilevamento o di routing insolito, ma elimina anche il confine delle porte a livello di container e aumenta la probabilità di conflitti sulle porte dell’host.

Un confronto aggiornato tra reti bridge e host inquadra la scelta in base a prestazioni, isolamento, esposizione dei servizi e debug. Applica questi criteri al percorso di Immich, invece di presumere che la modalità host sia intrinsecamente più affidabile.

Se la modalità host risolve un sintomo, ripeti il test due volte e spiegane il motivo. Per esempio, verifica che lo stesso nome host, account, proxy e client falliscano sulla rete bridge e funzionino sulla rete host, mentre i log dell’applicazione restano altrimenti normali. Se il risultato non è ripetibile, il cambio di modalità potrebbe aver soltanto mascherato uno stato DNS o di rete obsoleto.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Mantieni il proxy inverso su un percorso esplicito e ripristinabile

Un proxy inverso dovrebbe raggiungere Immich tramite una definizione upstream stabile anche dopo il riavvio dei container. Su una rete bridge, preferisci una rete definita dall’utente condivisa e un upstream basato sul nome del servizio, anziché un indirizzo IP del container copiato manualmente. In modalità host, indirizza il proxy all’indirizzo e alla porta dell’host previsti, verificando l’assenza di conflitti.

Il modello di test tra host e bridge di ZimaSpace utilizza una regola condizionale analoga: la semplicità del rilevamento può giustificare la modalità host, mentre l’isolamento e l’integrazione esplicita con il proxy favoriscono una rete bridge. Immich usa protocolli diversi, quindi riutilizza il metodo decisionale, non le ipotesi sulle porte specifiche di Plex.

Riavvia prima solo il proxy, poi solo Immich e infine l’intero stack. Una progettazione corretta ripristina ogni volta gli stessi percorsi locali e remoti senza modificare gli indirizzi IP. Una topologia che richiede il ricollegamento manuale dopo una ricreazione non è abbastanza stabile, indipendentemente dall’uso della rete host o bridge.

Scegli la modalità che supera lo stesso test di accettazione con meno rischi

Testa l’accesso web locale, la connessione dell’app mobile, un caricamento di piccole dimensioni, uno di grandi dimensioni, l’accesso tramite proxy inverso, lo stato dei servizi tra loro e un riavvio completo. Registra latenza e malfunzionamenti, ma non dare troppo peso a differenze minime di velocità se entrambe le modalità restano molto al di sotto del limite della rete.

Scegli la rete bridge quando tutte le funzioni superano i test e trai vantaggio dall’esposizione esplicita, dal DNS dei container e dall’isolamento. Scegli la rete host quando un percorso necessario fallisce in modo riproducibile su una rete bridge configurata correttamente e la modalità host lo risolve senza creare conflitti di porte o ampliare l’esposizione oltre il livello accettato.

Se entrambe le modalità falliscono nello stesso modo, smetti di alternare le impostazioni di rete. La causa è più probabilmente nel DNS, nel TLS, nelle intestazioni del proxy, nell’autenticazione, nel firewall, nell’archiviazione o nell’applicazione stessa. Conserva la richiesta e i log relativi al fallimento, torna alla topologia nota più semplice e funzionante e analizza il confine successivo.