Jak ustalić, która zależność kontenera powoduje pętlę restartów

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.

How to Identify Which Container Dependency Is Causing a Restart Loop

Zidentyfikuj pierwszą zależność, która staje się niedostępna przed zakończeniem działania aplikacji, zamiast uznawać każdy kontener uruchamiający się ponownie za główną przyczynę problemu.

W stosie Docker Compose widoczna aplikacja może zapętlać działanie, ponieważ baza danych wciąż się uruchamia, Redis jest nieosiągalny, DNS zwraca niewłaściwą usługę, brakuje montowania bind, zmienił się sekret, migracja się nie powiodła albo aplikacja została zakończona z powodu presji pamięci. Najszybsza diagnoza polega na zarejestrowaniu pierwszego zakończenia działania i błędu zależności, wstrzymaniu automatycznych restartów, a następnie przetestowaniu każdej wymaganej usługi z tej samej sieci i przy użyciu tych samych danych uwierzytelniających, których używa wadliwy kontener.

Znajdź pierwszy kontener, który ulega awarii, a nie ten, który robi najwięcej hałasu

Wyświetl liczbę restartów, bieżący stan, stan zdrowia, ostatni kod zakończenia i czas uruchomienia każdej usługi w stosie. Uporządkuj oś czasu tak, aby najwcześniejsza awaria pojawiła się przed rozpoczęciem ponownego łączenia lub restartowania kontenerów zależnych.

Przewodnik Netdata dotyczący pętli restartów pokazuje, jak kody zakończenia i stany pozwalają odróżnić zabicia OOM, błędy segmentacji, kontrolowane zakończenia i zatrzymania związane ze stanem zdrowia. Sygnał OOMKilled lub kod zakończenia może wyeliminować konieczność diagnozowania zależności, jeśli aplikacji w rzeczywistości brakuje pamięci lub ulega ona wewnętrznej awarii.

Jeśli jedna z zależności ulegnie awarii jako pierwsza, zbadaj ją przed aplikacją. Jeśli aplikacja kończy działanie jako pierwsza z błędem odmowy połączenia, przekroczenia limitu czasu, uwierzytelniania lub braku pliku, przyporządkuj ten komunikat dokładnie do zależności, z której próbowała skorzystać.

Wstrzymaj lawinę restartów i zarejestruj jedno czyste wystąpienie awarii

Tymczasowo wyłącz lub zastąp zasadę restartowania dla usługi, której dotyczy problem, i uruchom ją raz na pierwszym planie albo sprawdź kompletne logi z jednej próby uruchomienia. Zachowaj znaczniki czasu z demona Dockera i każdej zależności.

Powtarzające się automatyczne restarty mogą zastąpić pierwszy istotny błąd późniejszymi błędami połączenia. Kontener restartujący się co kilka sekund może również przeciążyć bazę danych, resolver DNS lub wolumin logów i wywołać objawy wtórne.

Podczas tego przechwytywania nie usuwaj kontenerów, woluminów ani baz danych. Zatrzymaj tylko lawinę restartów, odtwórz problem raz i zapisz środowisko, montowania, dołączenia do sieci, polecenie oraz stan zakończenia przed zmianą konfiguracji.

Zmapuj wszystkie zależności potrzebne kontenerowi do uzyskania gotowości

Zapisz wymaganą przez aplikację bazę danych, pamięć podręczną, kolejkę komunikatów, magazyn obiektów, resolver DNS, dostawcę tożsamości, montowane pliki, sekrety i zewnętrzne interfejsy API. Uwzględnij oczekiwaną nazwę usługi, port, protokół, nazwę użytkownika, bazę danych i ścieżkę.

Dash0 wyjaśnia, że kolejność uruchamiania w Compose nie oznacza automatycznie gotowości procesu wewnątrz zależności — aplikacja może uruchomić się, gdy Postgres wciąż się inicjalizuje. Rozwiązaniem jest oczekiwanie na zdrowy stan zależności, a nie tylko na jej stan działania.

Oznacz zależności jako wymagane lub opcjonalne. Brak opcjonalnej usługi metryk nie powinien powodować restartu głównej aplikacji, natomiast niedostępna baza danych może wymagać kontrolowanego oczekiwania, ponawiania prób lub zatrzymania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Przetestuj każdą zależność z sieci wadliwego kontenera

Użyj tymczasowego kontenera diagnostycznego dołączonego do tej samej sieci albo uruchom obsługiwaną powłokę, zanim aplikacja zakończy działanie. W tej kolejności przetestuj DNS nazwy usługi, port TCP, TLS, uwierzytelnianie, zapytanie do bazy danych i wymaganą ścieżkę.

Przewodnik Last9 dotyczący testów zdrowia w Compose wskazuje, że testy gotowości uniemożliwiają uruchomienie usług zależnych, dopóki kluczowe komponenty nie będą faktycznie odpowiadać. Przydatny test sprawdza działanie usługi wymagane przez klientów, zamiast tylko potwierdzać istnienie procesu.

Jeśli DNS nie działa, sprawdź członkostwo w sieci i aliasy. Jeśli połączenie TCP jest możliwe, ale uwierzytelnianie się nie udaje, porównaj sekrety i użytkowników. Jeśli logowanie działa, ale brakuje oczekiwanego schematu, zasobnika, kolejki lub katalogu, napraw inicjalizację, a nie sieć.

Sprawdź montowania, sekrety i migracje jako zależności

Porównaj bieżące montowania bind, woluminy nazwane, uprawnienia, właścicieli, pliki środowiskowe, pliki sekretów i wersję aplikacji z ostatnim działającym wdrożeniem. Kontener może mieć dostęp do bazy danych, a mimo to restartować się, ponieważ plik konfiguracyjny jest tylko do odczytu lub migracja nie może zapisywać.

Studium przypadku dotyczące uruchamiania kontenera pokazuje, że kolejność zależności oparta na stanie zdrowia może zapobiec awarii aplikacji przed uzyskaniem gotowości bazy danych. Warunkowa sekwencja uruchamiania jest szczególnie ważna podczas pierwszego uruchomienia i migracji.

Uruchom migracje raz przy widocznych logach i wykonaj kopię zapasową bazy danych przed ponowieniem destrukcyjnych operacji. Jeśli zmieniła się wersja aplikacji, sprawdź, czy wersja zależności i ścieżka aktualizacji schematu są obsługiwane.

Ponownie włączaj usługi w kolejności zależności i sprawdź stabilność

Najpierw uruchom zależność najniższego poziomu, poczekaj na jej rzeczywisty test zdrowia, następnie uruchom kolejną warstwę i na końcu aplikację. Rejestruj liczbę restartów i zmiany stanu zdrowia przez kilka kolejnych interwałów testów.

Przewodnik ZimaSpace dotyczący awarii DNS po stronie kontenera opisuje jedną ze ścieżek zależności, która może ujawniać się wyłącznie w środowisku aplikacji.

Problem jest rozwiązany dopiero wtedy, gdy aplikacja uruchamia się raz, wszystkie wymagane zależności pozostają zdrowe, migracje kończą się pomyślnie, a celowy restart zależności wywołuje kontrolowane ponawianie prób lub odzyskiwanie działania zamiast kolejnej pętli. Przywróć zasadę restartowania dopiero wtedy, gdy główna awaria jest możliwa do zaobserwowania i ograniczona.