Jak dopasować zasady restartowania Dockera do baz danych, procesów roboczych i aplikacji internetowych

Dopasuj zasady restartowania Dockera do cyklu życia usługi i semantyki kodów wyjścia, zamiast przypisywać unless-stopped każdemu kontenerowi w pliku Compose.

Zasady restartowania reagują na zakończenie głównego procesu kontenera; kontrola kondycji może oznaczyć wciąż działający proces jako niesprawny, ale nie uruchomi go automatycznie ponownie. Dlatego bazy danych, workery, aplikacje internetowe, migracje i zadania zaplanowane wymagają różnych ustawień, zależnie od tego, czy mają działać stale, co oznacza prawidłowe zakończenie oraz jak należy sygnalizować powtarzające się błędy.

Oddziel zachowanie przy restarcie od kondycji i gotowości

Zasada restartowania określa, czy Docker powinien ponownie uruchomić kontener po zatrzymaniu jego procesu. Kontrola kondycji określa, czy działająca usługa może wykonać zdefiniowaną operację. Gotowość zależności określa, czy inna usługa powinna już się uruchomić. Te mechanizmy rozwiązują powiązane, ale różne problemy.

Artykuł z 2026 roku wyjaśniający rozdział kontroli kondycji i restartowania opisuje to rozdzielenie oraz pokazuje, jak warunki kondycji w Compose mogą opóźnić uruchomienie zależnej usługi do momentu, gdy usługa będzie rzeczywiście gotowa.

Nie oczekuj, że restart: always naprawi niesprawny proces aplikacji internetowej, który nigdy się nie kończy, ani że sama kontrola kondycji go zrestartuje. Spraw, aby aplikacja kończyła działanie, gdy dalsza praca jest niebezpieczna, dodaj zewnętrzny mechanizm naprawczy lub skonfiguruj alerty dotyczące stanu niesprawności zgodnie z projektem usługi.

Używaj trwałych zasad restartowania dla długo działających baz danych

Zwykle oczekuje się, że baza danych na serwerze domowym uruchomi się ponownie po restarcie hosta lub demona Dockera. unless-stopped jest często praktycznym ustawieniem domyślnym, gdy celowe zatrzymanie przez administratora powinno pozostać respektowane; always jest właściwe, gdy zgodnie z założeniami ponowne uruchomienie ma ignorować stan ręcznego zatrzymania.

Artykuł z lipca 2026 roku opisujący działanie zasad restartowania po zakończeniu procesu przedstawia różnice między no, on-failure, always i unless-stopped, w tym fakt, że zasada reaguje na zakończenie procesu, a nie na stan kondycji.

Baza danych potrzebuje również rzeczywistej kontroli kondycji i trwałego magazynu danych. Wielokrotne restartowanie PostgreSQL nie naprawi pełnego dysku, nieprawidłowej konfiguracji, uszkodzonego stanu ani niezgodnej migracji. Zamiast uznawać restarty za skuteczną odporność, skonfiguruj alerty dotyczące ich powtarzania.

Dobierz zasadę dla workera na podstawie semantyki kolejki i zakończenia

Długo działający worker kolejki może wymagać unless-stopped, jeśli powinien stale pobierać zadania. Worker wykonujący skończone zadanie lub proces wsadowy może używać on-failure:N, aby przejściowe błędy otrzymały ograniczoną liczbę ponowień, a trwała awaria była widoczna po zatrzymaniu procesu.

Najnowszy artykuł o ograniczonych ponowieniach on-failure podkreśla, że zachowanie przy ponowieniach powinno odpowiadać temu, czy proces ma działać bezterminowo, czy może zakończyć się normalnie.

Ustal, co oznacza kod wyjścia 0 w obrazie workera. Jeśli oznacza „zadanie ukończone”, always może zmienić pomyślnie zakończone zadanie jednorazowe w nieskończoną pętlę. Jeśli worker ma działać jako demon, nieoczekiwane prawidłowe zakończenie może nadal uzasadniać automatyczne ponowne uruchomienie przez unless-stopped.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Utrzymuj aplikacje internetowe w działaniu, ale uzależnij je od rzeczywistych zależności

Większość samodzielnie hostowanych aplikacji internetowych ma być stale dostępna, dlatego unless-stopped jest zwykle łatwiejsze do zrozumienia niż ograniczona zasada uruchamiania wyłącznie po błędzie. Ustawienie restartowania nie eliminuje potrzeby zapewnienia gotowości bazy danych, pamięci podręcznej, DNS-u, sekretów i zamontowanych ścieżek.

Powiązany poradnik diagnostyczny ZimaSpace dotyczący pętli restartów kontenera spowodowanych zależnościami pokazuje, dlaczego wielokrotne restartowanie widocznej aplikacji może przesłonić wcześniejszą awarię bazy danych, pamięci podręcznej, montowania, migracji lub pamięci.

W odpowiednich przypadkach używaj kontroli kondycji zależności do ustalania kolejności uruchamiania i ograniczaj liczbę ponowień aplikacji. Usługa internetowa, która ulega awarii co pięć sekund do momentu uruchomienia PostgreSQL, jest mniej obserwowalna niż usługa, która czeka na gotowość i wykonuje jedno prawidłowe uruchomienie.

Nadaj migracjom i zadaniom jednorazowym skończony cykl życia

Kontenery migracji, importery, zadania konserwacyjne i jednorazowe zadania inicjalizacyjne nie są zwykłymi demonami. Ich stan powodzenia często oznacza „zakończ działanie kodem 0 i pozostań zatrzymany”. Użycie always lub unless-stopped może nieumyślnie uruchamiać ukończoną pracę ponownie.

Jawnie konfiguruj jednorazowe narzędzia operacyjne, zamiast pozwalać, aby stały się ukrytymi usługami działającymi bez przerwy. Migracja lub importer powinny mieć skończony stan powodzenia, który pozostaje widoczny po zakończeniu polecenia.

Użyj restart: "no", gdy błąd powinien zatrzymać proces do analizy, albo ograniczonego on-failure tylko wtedy, gdy ponowienie polecenia jest bezpieczne. W przypadku migracji schematu przed automatyzacją ponowień potwierdź, że powtórzenie częściowo zastosowanej migracji jest obsługiwane.

Testuj zasadę na rzeczywistych scenariuszach awarii

Dla każdej usługi przetestuj prawidłowe zakończenie procesu, awarię z kodem różnym od zera, restart hosta, restart demona Dockera, ręczne zatrzymanie, stan niesprawności przy działającym procesie oraz niedostępną zależność. Zanim uznasz konfigurację za odporną, zapisz oczekiwany stan po każdym zdarzeniu.

Monitoruj licznik restartów i skonfiguruj alert, gdy w określonym przedziale czasu przekroczy on niewielki próg. Automatyczny restart powinien skracać czas odzyskiwania po przejściowej awarii; nie powinien ukrywać trwałego błędu przez tworzenie nieskończonego strumienia nowych kontenerów.

Dobra macierz zasad jest jednoznaczna: długo działające bazy danych i aplikacje internetowe uruchamiają się ponownie po restartach infrastruktury, workery działające jako demony odzyskują sprawność zgodnie z semantyką kolejki, zadania skończone zatrzymują się po zakończeniu, a kontrole kondycji i gotowości ujawniają awarie, których zasada restartowania nie jest w stanie wykryć.