Co powoduje, że zaplanowane zadania uruchamiają się na hoście, ale nie wewnątrz kontenera?

Zaplanowane zadania kończą się niepowodzeniem wewnątrz kontenera, gdy harmonogram, środowisko, użytkownik, czas lub wymagana ścieżka uruchomieniowa różnią się od działającego kontekstu hosta.

Polecenie, które działa w interaktywnej powłoce hosta, może zależeć od zmiennej PATH hosta, profilu logowania, strefy czasowej, zamontowanych plików, danych uwierzytelniających, systemu DNS lub działającego demona cron. W kontenerze nic z tego nie jest gwarantowane. Zacznij od sprawdzenia, czy proces harmonogramu działa, a następnie uruchom dokładne zadanie z tym samym minimalnym środowiskiem i użytkownikiem, których używa cron.

Potwierdź, że proces harmonogramu rzeczywiście działa

Sprawdź aktywne procesy kontenera i polecenie startowe. Zainstalowanie pakietów cron w obrazie nie uruchamia demona, a kontener zwykle uruchamia wyłącznie skonfigurowany punkt wejścia lub polecenie.

Wieloletnia dyskusja na Stack Overflow dotycząca crona w Dockerze koncentruje się na konieczności uruchomienia harmonogramu wewnątrz kontenera, zamiast zakładać, że usługa hosta obsługuje jego crontab. Pierwszym rozstrzygającym sprawdzeniem jest to, czy proces cron jest aktywny, gdy nadejdzie zaplanowany czas.

Jeśli żaden harmonogram nie działa, wybierz świadomie jedno rozwiązanie: uruchom cron lub harmonogram obsługujący kontenery jako proces pierwszoplanowy, użyj osobnego kontenera z zadaniem albo wywołuj kontener aplikacji z crona hosta. Nie dodawaj drugiego, niezarządzanego demona bez ustalenia sposobu rejestrowania jego działania i zatrzymywania.

Uruchom dokładne polecenie z minimalnym środowiskiem

Skopiuj zaplanowane polecenie i uruchom je wewnątrz kontenera jako docelowy użytkownik zadania, z ograniczonym środowiskiem. Zapisz standardowe wyjście, standardowe wyjście błędów, kod zakończenia, bieżący katalog oraz zmienne środowiskowe.

Znacząca część zadań cron w kontenerach kończy się niepowodzeniem, ponieważ cron nie ładuje profilu interaktywnej powłoki, który dostarczał zmienną PATH, środowiska uruchomieniowe języków, tokeny API lub zmienne aplikacji. Przewodnik po harmonogramach skoncentrowanych na kontenerach podkreśla zachowanie wymaganego środowiska zadania jako kluczowy wymóg.

Jeśli polecenie kończy się niepowodzeniem tylko w minimalnym środowisku, dodaj jawne ścieżki bezwzględne i wyłącznie niezbędne zmienne. Unikaj wczytywania pełnego profilu użytkownika, który może wprowadzać niezwiązane aliasy, znaki zachęty lub sekrety.

Sprawdź PATH, powłokę, katalog roboczy i użytkownika

Zastąp polecenia i ścieżki względne bezwzględnymi. Potwierdź, że wybrana powłoka istnieje oraz że składnia crontaba odpowiada implementacji crona zainstalowanej w obrazie.

Uruchom zadanie jako skonfigurowany użytkownik crona i sprawdź uprawnienia odczytu, zapisu oraz wykonywania dla skryptów, konfiguracji, gniazd i katalogów wyjściowych. Ręczny test wykonany wyłącznie jako root nie dowodzi, że nieuprzywilejowane zadanie zaplanowane może zakończyć się powodzeniem.

Ustaw katalog roboczy w poleceniu lub skrypcie opakowującym. Jeśli zadanie działa po zmianie wyłącznie katalogu lub użytkownika, zachowaj ten jawnie określony kontekst w konfiguracji objętej kontrolą wersji, zamiast polegać na domyślnych ustawieniach kontenera.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Porównaj czas i strefę czasową kontenera z harmonogramem

Wyświetl bieżący czas, strefę czasową i następne planowane uruchomienie wewnątrz kontenera. Kontenery współdzielą zegar jądra hosta, ale do wyświetlania czasu i interpretacji crona mogą używać UTC lub plików innej strefy czasowej.

Przypadek opisany w Server Fault pokazuje, jak czas kontenera może być wyświetlany w innej strefie czasowej, nawet gdy host pokazuje czas lokalny, przez co prawidłowy crontab uruchamia się o niewłaściwej pozornej godzinie lokalnej.

Wybierz jedną, jawną strategię dotyczącą strefy czasowej i zweryfikuj ją po ponownym utworzeniu kontenera. Nie kompensuj problemu przez przesunięcie wyrażenia cron przy niejednoznacznej bazowej strefie czasowej, ponieważ zmiana czasu letniego lub obrazu może ponownie przesunąć uruchomienie.

Zweryfikuj montowania, sekrety, dostęp sieciowy i czas życia kontenera

Sprawdź, czy każdy katalog wejściowy, ścieżka wyjściowa, sekret, gniazdo i plik konfiguracyjny istnieje wewnątrz kontenera w czasie uruchamiania zadania. Następnie przetestuj dostęp do DNS, bazy danych, API lub NAS z tej samej sieci kontenera.

Hostowy cron może widzieć ścieżki hosta, których nie ma w kontenerze. Przypadek Nextcloud w Dockerze pokazuje, jak zadanie działające w tle może wydawać się skonfigurowane, podczas gdy rzeczywiste polecenie kontenera, użytkownik lub ścieżka aplikacji nadal uniemożliwiają oczekiwane wykonywanie w tle.

Potwierdź również, że kontener nadal działa, gdy nadejdzie zaplanowany czas. Krótkotrwałe kontenery aplikacji i zastępowanie wdrożeń mogą zakończyć działanie wewnętrznego harmonogramu, zanim długotrwałe lub rzadko uruchamiane zadania zostaną ukończone.

Wybierz jedną granicę planowania i potwierdź działanie bez nadzoru

Wyznacz jednego właściciela harmonogramu: cron hosta wywołujący docker exec, dedykowany kontener harmonogramu albo harmonogram pierwszoplanowy wewnątrz obrazu aplikacji. Zduplikowane harmonogramy mogą uruchomić to samo zadanie konserwacyjne dwukrotnie.

Przewodnik ZimaSpace dotyczący testowania DNS po stronie kontenera opisuje jedną z przyczyn wtórnych, gdy harmonogram się uruchamia, ale nie może połączyć się z inną usługą.

Problem jest rozwiązany dopiero wtedy, gdy zadanie uruchamia się o zamierzonej porze po ponownym utworzeniu kontenera i restarcie hosta, generuje przechwycone logi, używa oczekiwanego użytkownika i ścieżek oraz tworzy zweryfikowany rezultat aplikacji. Pomyślne ręczne wykonanie polecenia nie jest testem końcowym.