Dlaczego sprawdzanie stanu kontenera kończy się niepowodzeniem, mimo że aplikacja nadal się otwiera?

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 a Container Health Check Fail While the App Still Opens? - Zima Store Online

Kontener może nadal działać, mimo że jego test kondycji kończy się niepowodzeniem, ponieważ sonda sprawdza inne polecenie, adres, użytkownika lub warunek gotowości niż ścieżka używana przez przeglądarkę.

Na serwerze domowym aplikacja może otwierać się przez odwrotny serwer proxy, podczas gdy Docker uruchamia polecenie sprawdzające wewnątrz kontenera, kierując je do localhost, brakującego narzędzia, niewłaściwego portu lub tymczasowo niedostępnej zależności. Zacznij od odtworzenia dokładnej sondy wewnątrz kontenera, a następnie porównaj jej cel i oczekiwany wynik z rzeczywistą ścieżką użytkownika, zanim zwiększysz liczbę ponowień lub wyłączysz test kondycji.

Porównaj, co sprawdza przeglądarka, z tym, co sprawdza test kondycji

Zapisz adres URL i ścieżkę sieciową, które poprawnie otwierają aplikację. Sprawdź, czy przeglądarka łączy się z odwrotnym serwerem proxy, opublikowanym portem hosta, lokalnym adresem IP czy bezpośrednio z kontenerem.

Docker wykonuje skonfigurowaną sondę wewnątrz kontenera, więc może ona sprawdzać inny punkt końcowy niż przeglądarka. W jednym z przypadków opisanych w społeczności Dockera test kondycji kończył się niepowodzeniem, ponieważ obraz nie zawierał polecenia curl używanego przez sondę, mimo że sam proces usługi nadal mógł działać.

Jeśli działająca ścieżka przeglądarki przechodzi przez inny serwer proxy lub port, nie traktuj tego jako dowodu, że wewnętrzny cel sondy jest prawidłowy. Zapisz obie ścieżki i wskaż pierwszy różniący je komponent.

Uruchom dokładne polecenie testu kondycji wewnątrz kontenera

Skopiuj polecenie testu kondycji dokładnie, wraz z jego formą powłoki, adresem URL, flagami, danymi uwierzytelniającymi i zmiennymi środowiskowymi. Wykonaj je wewnątrz działającego kontenera jako ten sam użytkownik i zapisz kod wyjścia oraz dane wyjściowe.

Kontener oznaczony jako niesprawny może nadal mieć działający proces, ponieważ stan kondycji odzwierciedla wynik sondy, a nie to, czy użytkownicy mogą załadować jedną stronę. Procedura diagnostyczna Netdata rozróżnia niepowodzenie sondy od niepowodzenia procesu przed zmianą zachowania przy ponownym uruchamianiu.

Jeśli polecenie działa ręcznie, porównaj użytkownika wykonującego polecenie, powłokę, katalog roboczy, środowisko i czas wykonania używane przez automatyczny test. Jeśli ręczne wykonanie kończy się niepowodzeniem, błąd wskaże teraz kolejną warstwę bez oczekiwania na następny interwał testu kondycji.

Sprawdź narzędzie sondy, powłokę, PATH i użytkownika

Upewnij się, że każdy plik wykonywalny używany w poleceniu testu kondycji istnieje w bieżącym obrazie i może zostać uruchomiony przez użytkownika kontenera. Minimalne obrazy mogą nie zawierać curl, wget, bash, narzędzi DNS ani magazynów certyfikatów.

Sondy w formie powłoki i w formie exec działają inaczej. Cudzysłowy, potoki, rozwijanie zmiennych i polecenia złożone wymagają dostępnej powłoki, natomiast bezpośrednie polecenie wymaga pełnej ścieżki do pliku wykonywalnego, gdy środowisko testu kondycji ma ograniczoną wartość PATH.

Uruchom polecenie z użyciem ścieżki bezwzględnej i właściwego użytkownika usługi. Napraw obraz lub sondę zamiast instalować narzędzia interaktywnie, ponieważ ręczna zmiana kontenera zniknie przy następnym przebudowaniu.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zweryfikuj wewnętrzny adres, port i protokół

Sprawdź, na jakim porcie aplikacja nasłuchuje wewnątrz kontenera, i porównaj go z adresem URL sondy. Opublikowany port hosta, taki jak 8080:80, nie oznacza, że usługa nasłuchuje na porcie 8080 wewnątrz kontenera.

Testy kondycji powinny sprawdzać stan aplikacji kontrolowany przez kontener. Praktyczny przewodnik Dash0 wskazuje, że sonda może wywoływać punkt końcowy HTTP lub sprawdzać proces, ale punkt końcowy musi odzwierciedlać rzeczywisty stan gotowości kontenera, a nie trasę dostępną wyłącznie przez zewnętrzny serwer proxy.

Testuj 127.0.0.1, adres nasłuchiwania kontenera i nazwę usługi tylko tam, gdzie każdy z tych celów jest właściwy. Jeśli aplikacja nasłuchuje wyłącznie na gnieździe Unix lub innym interfejsie, zmień sondę tak, aby korzystała z rzeczywistego wewnętrznego punktu wejścia.

Oddziel powolne uruchamianie od trwałego niepowodzenia

Zmierz, ile czasu aplikacja, migracja bazy danych, rozgrzewanie pamięci podręcznej lub ładowanie modelu potrzebują, zanim właściwy punkt końcowy zacznie odpowiadać. Porównaj ten czas z wartościami start_period, interval, timeout i retries.

Compose może wstrzymać uruchamianie usług zależnych, gdy zależność jest nadal oznaczona jako niesprawna, nawet jeśli później osiągnie stan gotowości. W zgłoszonej regresji Compose usługa stawała się sprawna dopiero po tym, jak niepowodzenie zależności zatrzymało już stos, ujawniając zbyt wąskie okno testu kondycji podczas uruchamiania.

Zwiększaj czasy tylko wtedy, gdy logi potwierdzają, że aplikacja prawidłowo kontynuuje pracę. Dłuższe ponowienia nie powinny ukrywać niewłaściwego portu, nieudanej migracji, brakującego certyfikatu ani nieosiągalnej bazy danych.

Utrzymuj sondę wąską i sprawdź odzyskiwanie

Ustal, czy test kondycji ma odzwierciedlać aktywność procesu, lokalną gotowość aplikacji czy głębszy łańcuch zależności. Nie oznaczaj lokalnego kontenera jako niesprawnego tylko dlatego, że opcjonalne zewnętrzne API jest niedostępne.

Przewodnik ZimaSpace dotyczący znajdowania pierwszej niesprawnej zależności to kolejny krok, gdy aplikacja nie może osiągnąć gotowości bez bazy danych, pamięci podręcznej lub usługi sieciowej.

Problem jest rozwiązany, gdy dokładna sonda automatyczna działa poprawnie po normalnym uruchomieniu, kontener pozostaje sprawny podczas ponownego uruchamiania zależności, a rzeczywisty przepływ pracy aplikacji pozostaje dostępny. Sonda powinna być wystarczająco rygorystyczna, aby wykrywać uszkodzoną usługę, ale jednocześnie na tyle wąska, aby unikać fałszywych niepowodzeń spowodowanych przez niezwiązane systemy.