W przypadku większości wdrożeń Immich opartych na Dockerze własna sieć typu bridge jest lepszym domyślnym wyborem; sieć hosta to ukierunkowane obejście problemu, a nie uniwersalne ulepszenie wydajności.
Immich potrzebuje przede wszystkim niezawodnych połączeń między klientem a serwerem, serwerem a bazą danych, serwerem a Redisem, usługą uczenia maszynowego oraz odwrotnym proxy. Oba tryby sieciowe mogą je zapewnić. Wybór należy oprzeć na odtworzeniu rzeczywistej awarii lub wymagania dotyczącego dostępu, testowaniu jednego trybu naraz oraz pozostawieniu konfiguracji, którą najłatwiej obserwować i przywracać.
Zacznij od ścieżek, których Immich faktycznie potrzebuje
Przedstaw stos jako połączenia, a nie kontenery: klienci łączą się z publicznym lub lokalnym punktem dostępu Immich; proxy łączy się z serwerem Immich; aplikacja łączy się z PostgreSQL i Redisem; a serwer łączy się z usługą uczenia maszynowego. Zaznacz, które połączenia pozostają wewnątrz Dockera, a które przekraczają granicę hosta.
Własna sieć typu bridge zapewnia kontenerom oddzielną przestrzeń nazw sieci, a jednocześnie pozwala usługom w tej samej sieci odnajdywać się nawzajem po nazwie usługi. Przydatny w tym rozróżnieniu jest przegląd sieci Dockera w trybach sieciowych Dockera: opublikowane porty obsługują klientów hosta lub zewnętrznych, natomiast DNS kontenerów obsługuje ruch między usługami.
Jeśli każda wymagana ścieżka działa już w sieci bridge, sieć hosta nie rozwiązała żadnego udowodnionego problemu. Pozostaw sieć bridge i udokumentuj nazwy usług, sieci oraz opublikowane porty, aby późniejszą zmianę proxy lub konfiguracji Compose można było sprawdzić względem znanej topologii.
Wybierz własną sieć bridge, gdy ważne są izolacja i stabilne nazwy usług
Tryb bridge pozwala usługom Immich komunikować się w jawnie określonej sieci aplikacji bez wystawiania portu każdego kontenera na hoście. Jest to szczególnie przydatne, gdy odwrotne proxy korzysta z tej samej sieci i może kierować ruch bezpośrednio do nazwy usługi Immich, ograniczając zależność od adresu IP kontenera, który może się zmienić po jego odtworzeniu.
Analiza zalet i wad sieci hosta w środowiskach homelab zauważa, że usunięcie translacji NAT Dockera rzadko przynosi istotny wzrost wydajności przy typowym ruchu internetowym w homelabie. Ważniejsze różnice dotyczą izolacji przestrzeni nazw, publikowania portów oraz sposobu, w jaki usługi odnajdują się nawzajem.
Tryb bridge jest wadliwym rozwiązaniem dopiero wtedy, gdy wymaganej ścieżki nie można zrealizować lub pozostaje ona zawodna po prawidłowym skonfigurowaniu sieci, DNS, zapory i członkostwa proxy w sieci. Nie zmieniaj trybu tylko dlatego, że klient zgłasza „serwer niedostępny”; najpierw potwierdź, że żądanie rzeczywiście zatrzymuje się na granicy Dockera.
Używaj sieci hosta tylko w przypadku konkretnego, powtarzalnego wymagania
Tryb hosta umieszcza kontener w przestrzeni nazw sieci hosta, eliminując translację portów Dockera i zapewniając usłudze kontekst sieciowy hosta. Może to uprościć niektóre przypadki wykrywania usług lub nietypowego routingu, ale jednocześnie usuwa granicę portów na poziomie kontenera i zwiększa ryzyko konfliktów portów na hoście.
Aktualne porównania sieci bridge i hosta opierają wybór na wydajności, izolacji, ekspozycji usług i debugowaniu. Odnoś te kryteria do ścieżki Immich, zamiast zakładać, że tryb hosta jest z natury bardziej niezawodny.
Jeśli tryb hosta rozwiązuje jeden objaw, powtórz test dwukrotnie i wyjaśnij dlaczego. Potwierdź na przykład, że ta sama nazwa hosta, konto, proxy i klient zawodzą w trybie bridge, a działają w trybie hosta, podczas gdy logi aplikacji pozostają poza tym prawidłowe. Jeśli wyniku nie można powtórzyć, zmiana trybu mogła jedynie zamaskować problem z DNS-em lub nieaktualnym stanem sieci.
Utrzymuj odwrotne proxy na jawnej trasie, którą można łatwo przywrócić
Odwrotne proxy powinno docierać do Immich przez stabilną definicję serwera nadrzędnego także po ponownym uruchomieniu kontenerów. W sieci bridge preferuj współdzieloną własną sieć i serwer nadrzędny wskazujący nazwę usługi zamiast ręcznie kopiowanego adresu IP kontenera. W trybie hosta kieruj proxy na zamierzony adres i port hosta, sprawdzając przy tym, czy nie występują konflikty.
Wzorzec testowania sieci hosta i bridge opisany przez ZimaSpace stosuje analogiczną zasadę warunkową: prostota wykrywania usług może uzasadniać tryb hosta, natomiast izolacja i jawna integracja z proxy przemawiają za siecią bridge. Immich korzysta z innych protokołów, dlatego zastosuj samą metodę podejmowania decyzji, a nie założenia dotyczące portów właściwe dla Plexa.
Uruchom ponownie najpierw samo proxy, potem samego Immich, a następnie cały stos. Dobrze działające rozwiązanie za każdym razem przywraca te same trasy lokalne i zdalne bez edytowania adresów IP. Topologia wymagająca ręcznego przepinania po odtworzeniu kontenerów nie jest wystarczająco stabilna, niezależnie od tego, czy korzysta z sieci hosta, czy bridge.
Wybierz tryb, który przechodzi ten sam test akceptacyjny przy mniejszym ryzyku
Przetestuj logowanie przez lokalny interfejs WWW, połączenie aplikacji mobilnej, mały i duży upload, dostęp przez odwrotne proxy, zdrowie komunikacji między usługami oraz pełne ponowne uruchomienie. Zapisuj opóźnienia i awarie, ale nie przeceniaj niewielkich różnic przepustowości, jeśli w obu trybach wyniki pozostają znacznie poniżej limitu sieci.
Wybierz sieć bridge, gdy wszystkie funkcje działają, a korzystasz z jawnej ekspozycji, DNS-u kontenerów i izolacji. Wybierz sieć hosta, gdy wymagana ścieżka powtarzalnie zawodzi w prawidłowo skonfigurowanej sieci bridge, a tryb hosta ją naprawia bez powodowania konfliktów portów ani zwiększania ekspozycji ponad zaakceptowany poziom.
Jeśli oba tryby zawodzą w ten sam sposób, przestań przełączać ustawienia sieciowe. Przyczyna najprawdopodobniej leży w DNS-ie, TLS, nagłówkach proxy, uwierzytelnianiu, zaporze, magazynie danych lub samej aplikacji. Zachowaj nieudane żądanie i logi, wróć do prostszej, znanej jako działająca topologii i zdiagnozuj kolejną granicę.
Wsparcie i wskazówki
Więcej do przeczytania

Jak zoptymalizować połączenia z bazą danych Immich dla równoczesnych kontenerów
Nie zwiększaj najpierw wartości max_connections. Zmierz sesje Immich, zsumuj zapotrzebowanie wszystkich kontenerów, zachowaj rezerwę dla administratora i dostosuj tylko faktycznie potwierdzone wąskie gardło.

Jak zapobiegać duplikowaniu zadań lub importów w Immich
Oddziel powtarzające się zadania od zduplikowanych zasobów. Użyj jednej kanonicznej ścieżki pozyskiwania danych, kontroluj ponowne próby i zmiany ścieżek, a następnie przetestuj ponowne wprowadzanie...

Jak naprawić Immich po zapełnieniu woluminu bazy danych
Nigdy nie usuwaj dziennika WAL PostgreSQL, aby zwolnić miejsce. Zatrzymaj operacje zapisu w Immich, zachowaj stan bazy danych, bezpiecznie zwiększ pojemność, odzyskaj działanie PostgreSQL,...

