- Wykorzystanie natywnych zasad ponownego uruchamiania Dockera w celu radzenia sobie z awariami systemu.
- Implementacja niestandardowych skryptów i cron dla kontenerów w stanie nieprawidłowym.
- Zaawansowana integracja z systemd umożliwiająca kontrolę kolejności uruchamiania i wyłączania.
- Alternatywne, zewnętrzne narzędzia do monitorowania, takie jak Podman Quadlet.
Jestem pewien, że przydarzyło Ci się to: masz uruchomioną usługę w Doker który z tajemniczych przyczyn zacina się co kilka dni. Jak automatycznie ponownie uruchomić kontener Docker, gdy przestanie reagować? To frustrujące, gdy próbujesz optymalizować kod lub konfiguracje i nic nie działa, a potem okazuje się, że prosty, ręczny restart rozwiązuje problem i wszystko działa przez kolejny tydzień. Zamiast ciągle sprawdzać godzinę, idealnym rozwiązaniem jest skonfigurowanie systemu, który wykona tę brudną robotę za Ciebie.
Zarządzanie dostępnością kontenerów obejmuje więcej niż tylko zapewnienie ich automatycznego uruchamiania po włączeniu serwera. upewnij się, że odpowiadają poprawnie do żądań. Czasami kontener wydaje się Dockerowi „żywy”, ale aplikacja w nim zawarta nie odpowiada, co zmusza nas do poszukiwania rozwiązań, od podstawowych parametrów demona po tworzenie złożonych usług w systemie operacyjnym.
Natywne zasady ponownego uruchamiania Dockera
Najprostszym sposobem automatycznego ponownego uruchomienia kontenera Docker jest użycie flagi --restart podczas uruchamiania kontenera lub korzystania z polecenia docker update Jeśli kontener jest już utworzony, Docker oferuje kilka opcji w zależności od potrzeb. Na przykład, polityka zawsze Spowoduje to, że kontener zawsze zostanie uruchomiony ponownie, niezależnie od tego, czy proces zakończył się błędem, czy też sam demon Dockera został ponownie uruchomiony.
Jeśli wolisz coś bardziej chirurgicznego, chyba że zatrzymany To najlepszy wybór dla wielu. Ta konfiguracja jest identyczna z poprzednią, z tą różnicą, że jeśli ręcznie zatrzymasz kontener w celu konserwacji, Docker nie będzie próbował go włączyć. automatycznie po ponownym uruchomieniu serwera, respektując Twoją decyzję.
Dla tych, którzy chcą działać wyłącznie w odpowiedzi na krytyczne awarie, istnieje w przypadku awariiTa zasada uruchamia restart tylko wtedy, gdy kontener zakończy działanie z kodem wyjścia innym niż zero. Można to nawet ograniczyć, dodając maksymalną liczbę ponownych prób, zapobiegając w ten sposób wejściu systemu w nieskończoną pętlę restartów, jeśli błąd jest trwały i krytyczny.
Automatyzacja dla „niezdrowych” kontenerów
Tu robi się ciekawie. Czasami kontener nadal wyświetla się jako „Up” (włączony), ale jego stan zdrowia jest… niezdrowy Ponieważ nie przechodzi kontroli wewnętrznych. Poprzednie zasady są tutaj nieskuteczne, ponieważ proces technicznie nie jest martwy. Aby rozwiązać ten problem, możemy zaimplementować dyrektywę KONTROLA ZDROWIA w pliku Dockerfile lub Docker Compose, definiując polecenie (takie jak curl do konkretnego portu), aby sprawdzić, czy aplikacja odpowiada.
Po skonfigurowaniu kontroli stanu zdrowia możemy utworzyć Skrypt powłoki który działa co kilka minut za pomocą crontab z Linuksa. Ten skrypt powinien odfiltrować kontenery, które są w stanie unhealthy lub tych, którzy wyszli z kodem błędu 128 i uruchomili docker restart o nich.
Aby to wszystko działało sprawnie i aby możliwe było automatyczne ponowne uruchomienie kontenera Docker, konieczne jest, aby użytkownik uruchamiający zadanie cron miał odpowiednie uprawnienia. uprawnienia wymagane w grupie dockerW ten sposób system monitoruje otoczenie co 5 lub 10 minut i uruchamia każdą usługę, która stała się „zombie”, gwarantując niemal całkowitą dostępność bez ingerencji człowieka.
Zaawansowana integracja z systemd
Pracując w bardziej profesjonalnych środowiskach, możesz chcieć, aby Twoje kontenery zachowywały się w następujący sposób: natywne usługi LinuxZintegrować Doker Systemd umożliwia zarządzanie złożonymi zależnościami, takimi jak zapewnienie uruchomienia bazy danych przed aplikacją internetową. Osiąga się to poprzez tworzenie plików .service na trasie /etc/systemd/system/.
Możemy zaprojektować sekwencja wyłączania i włączania zasilania Kontrolowane. Za pomocą niestandardowych skryptów powiązanych z systemd można zatrzymać kontenery w odwrotnej kolejności niż ich zależności, aby zapobiec uszkodzeniu danych. Używając typu oneshot i konfigurowanie targets odpowiedni (taki jak multi-user.target o shutdown.target), serwer obsługuje cały cykl życia kontenera.
Inną skuteczną opcją automatycznego ponownego uruchomienia kontenera Docker w przypadku zaprzestania odpowiedzi jest użycie flagi --rm w połączeniu z systemd. Pozwala to na usunięcie kontenera po zatrzymaniu i utworzenie nowego z obrazu bazowego po uruchomieniu, zapewniając, że Pojemnik musi być zawsze czysty i w niezmienionym stanie.delegowanie trwałości danych wyłącznie do woluminów zewnętrznych.
Narzędzia zewnętrzne i nowoczesne alternatywy
Jeśli nie chcesz zawracać sobie głowy pisaniem skryptów Bash, dostępne są narzędzia innych firm. Istnieją aplikacje open source zaprojektowane specjalnie do restartowania kontenerów na podstawie ustalony harmonogramJest to bardzo przydatne w przypadku zadań cyklicznych, takich jak odnawianie certyfikatów SSL. Podobnie, narzędzia takie jak Uptime Kuma Umożliwiają monitorowanie stanu usług z poziomu wizualnego pulpitu nawigacyjnego i wysyłanie powiadomień do Telegrama lub Gotify w przypadku problemów. Wszystkie są bardzo przydatne do automatycznego restartowania kontenera Docker, gdy przestanie on odpowiadać.
Dla tych, którzy szukają lżejszej lub rodzimej alternatywy, Podman To doskonała opcja. Dzięki architekturze bezdemonowej i funkcjonalności CzwórkaUmożliwia tworzenie prostych plików deklaratywnych, które systemd automatycznie konwertuje na zoptymalizowane usługi, oferując o wiele bardziej organiczną integrację niż tradycyjny Docker.
Pełna kontrola nad cyklem życia usług wymaga połączenia ich wykorzystania zasady ponownego uruchamiania, stały nadzór poprzez kontrole stanu zdrowia a w bardziej złożonych przypadkach wsparcie systemd lub narzędzia monitorujące dzięki czemu Twoja infrastruktura jest solidna i nie wymaga od nikogo pamiętania o ręcznym ponownym uruchamianiu serwera co tydzień.
Redaktor specjalizujący się w zagadnieniach technologii i Internetu z ponad dziesięcioletnim doświadczeniem w różnych mediach cyfrowych. Pracowałem jako redaktor i twórca treści dla firm z branży e-commerce, komunikacji, marketingu online i reklamy. Pisałem także na portalach poświęconych ekonomii, finansom i innym branżom. Moja praca jest także moją pasją. Teraz, poprzez moje artykuły w Tecnobits, staram się odkrywać wszystkie nowości i nowe możliwości, jakie świat technologii oferuje nam każdego dnia, aby poprawić nasze życie.