Dlaczego Immich zachowuje się inaczej po ponownym uruchomieniu kontenera?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does Immich Behave Differently After a Container Restart?

Immich zmienia swoje zachowanie po ponownym uruchomieniu, ponieważ znikają nietrwałe pamięci podręczne, a zależności usług ponownie nawiązują połączenie, podczas gdy nieprawidłowo skonfigurowana trwałość danych może ujawnić poważniejszą utratę stanu.

Powolne pierwsze wyszukiwanie może być normalnym skutkiem „zimnego startu”; ekran pierwszej konfiguracji — nie. Przed zmianą danych sklasyfikuj objaw według czasu trwania i zakresu, ponieważ rozgrzewanie pamięci podręcznej, awaria zależności i brak trwałego magazynu wymagają zupełnie różnych działań.

Ponowne uruchomienie usuwa nietrwały stan procesu

Ponownie uruchomione procesy tracą modele przechowywane w pamięci, pule połączeń, skompilowane ścieżki i pamięci podręczne aplikacji. Pamięć podręczna stron hosta może przetrwać ponowne uruchomienie kontenera, ale ponowne uruchomienie hosta usuwa więcej elementów wcześniej załadowanych do pamięci. W rezultacie pierwsze żądanie wyszukiwania lub osi czasu może wymagać wykonania prac inicjalizacyjnych, których kolejne, natychmiastowe powtórzenia już nie wymagają.

Pomiar społeczności wykazał, że pierwsze inteligentne wyszukiwanie jest powolne, a kolejne powtórzenia znacznie szybsze, gdy model uczenia maszynowego ładuje się do pamięci GPU. Dokładny czas zależy od danego serwera, ale ta zmiana stanu wyjaśnia, dlaczego pojedyncze żądanie po ponownym uruchomieniu nie odzwierciedla stabilnego działania.

Wykonaj to samo znane żądanie trzy razy i zanotuj, czy czas odpowiedzi się stabilizuje. Jeśli tylko pierwsze żądanie jest powolne, a wyniki pozostają prawidłowe, sprawdź ładowanie przy zimnym starcie lub zasady przechowywania danych. Jeśli każde żądanie kończy się niepowodzeniem albo wygląda na to, że brakuje stanu, przestań traktować objaw jako rozgrzewanie pamięci podręcznej i zbadaj zależności oraz trwałość danych.

Kolejność uruchamiania zależności może ujawnić wyścig podczas startu

Immich zależy od czegoś więcej niż tylko procesu obsługującego interfejs internetowy. Baza danych, usługa koordynacji zadań, usługa uczenia maszynowego i zamontowane pliki multimedialne muszą stać się dostępne przy zgodnej konfiguracji. Kontener oznaczony jako działający może nadal się inicjalizować, więc wczesne żądanie może się nie powieść, mimo że chwilę później cały stos stanie się sprawny.

Raport o awarii po ponownym uruchomieniu opisuje przypadek, w którym Immich tracił dostęp do PostgreSQL lub Redis po pozornie niezwiązanych zmianach w pliku Compose. Ten opis nie dowodzi istnienia ogólnej wady produktu, ale pokazuje wartość diagnostyczną zestawienia błędów połączenia aplikacji z gotowością zależności i czasem ponownego uruchomienia.

Zbierz opatrzone znacznikami czasu logi aplikacji i wskazanej zależności z tego samego ponownego uruchomienia. Zweryfikuj rozpoznawanie DNS, dostępność portów, testy kondycji i dostępność zamontowanych zasobów wewnątrz kontenera. Jeśli automatyczne ponawianie próby przywraca usługę, popraw obsługę gotowości; jeśli usługa nigdy nie wraca, sprawdź bezpośrednio konfigurację i dane uwierzytelniające.

Trwały stan musi przetrwać zastąpienie kontenera

Obrazy i pliki bazy danych przechowywane wyłącznie w zapisywalnej warstwie kontenera znikają po jego zastąpieniu. Woluminy nazwane i montowania wiązane zachowują dane tylko wtedy, gdy wdrożenie odwołuje się do tej samej lokalizacji bazowej. Proste ponowne uruchomienie zwykle zachowuje te dane, ale zmiany w Compose lub ścieżkach mogą po cichu wskazać nowy, pusty magazyn.

Artykuł o ścieżce danych ZimaSpace wyjaśnia, że widoczna ścieżka kontenera nie pokazuje fizycznego magazynu ani domeny awarii znajdującej się za nią. Ma to kluczowe znaczenie po ponownym utworzeniu kontenera: identyczna wewnętrzna ścieżka może wskazywać inny katalog hosta, pusty wolumin albo niedostępne montowanie sieciowe.

Jeśli Immich wyświetla ekran pierwszej konfiguracji, nie twórz od razu zastępczej biblioteki. Sprawdź efektywne montowania, identyfikatory woluminów, właścicieli i logi bazy danych, a następnie porównaj je z ostatnim działającym wdrożeniem. Nowe zapisy mogą utrudnić odzyskiwanie, tworząc drugi zestaw stanu obok brakującego oryginału.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Skorzystaj z pięciominutowej klasyfikacji po ponownym uruchomieniu

W minucie zero zanotuj, które kontenery zostały ponownie uruchomione oraz czy zmieniono obrazy lub konfigurację. W pierwszej minucie sprawdź stan zależności i montowania. W trzeciej minucie powtórz jedno znane wyszukiwanie i oryginalne pobieranie. W piątej minucie zdecyduj, czy działanie się poprawia, usługa pozostaje niedostępna, czy wyświetlany jest pusty stan.

Raport o trwałości bazy danych opisuje powtarzające się ekrany pierwszej konfiguracji po ponownym uruchomieniu Compose, podczas gdy oczekiwany katalog bazy danych na hoście pozostawał pusty. To pojedyncze środowisko, ale pokazuje wyraźny sygnał awarii: znikanie trwałej tożsamości aplikacji po ponownym uruchomieniu wskazuje, że baza danych jest zapisywana w innym miejscu niż zamierzona trwała ścieżka.

Powiąż poprawiające się opóźnienia z zimnym stanem, błędy połączeń z uruchamianiem zależności, brak multimediów z montowaniami, a utratę użytkowników lub albumów z trwałością bazy danych. Zachowaj logi i bieżące mapowania woluminów przed wprowadzeniem jakichkolwiek zmian. Rozpocznij odzyskiwanie dopiero po potwierdzeniu, że oryginalny stan jest niedostępny, a nie tylko odłączony.