- Използване на собствените правила за рестартиране на Docker за справяне със системни повреди.
- Внедряване на персонализирани скриптове и cron за контейнери с нездравословни състояния.
- Разширена интеграция със systemd за контрол на последователността на стартиране и изключване.
- Алтернативи и инструменти за външен мониторинг, като например Podman Quadlet.
Сигурен съм, че това ви се е случвало: имате работеща услуга Докер който по мистериозни причини се забива на всеки няколко дни. Как автоматично да се рестартира Docker контейнер, когато спре да отговаря? Разочароващо е да се опитвате да оптимизирате код или конфигурации и нищо да не работи, само за да осъзнаете, че едно просто ръчно рестартиране решава проблема и поддържа всичко да работи още една седмица. Вместо постоянно да проверявате часа, идеалното решение е да настроите система, която да върши тази мръсна работа вместо вас.
Управлението на наличността на контейнерите включва повече от просто осигуряване на автоматичното им стартиране, когато сървърът е включен. уверете се, че отговарят правилно към заявките. Понякога контейнерът изглежда „жив“ за Docker, но приложението вътре не реагира, което ни принуждава да търсим решения, вариращи от основни параметри на демона до създаването на сложни услуги в операционната система.
Правила за рестартиране на Docker Native
Най-лесният начин за автоматично рестартиране на Docker контейнер е чрез използване на флага --restart при стартиране на контейнер или използване на командата docker update Ако контейнерът вече е създаден, Docker предлага няколко опции в зависимост от вашите нужди. Например, политиката винаги Това ще доведе до рестартиране на контейнера винаги, независимо дали процесът е завършил с грешка или дали самият Docker демон е бил рестартиран.
Ако предпочитате нещо по-хирургично, освен ако не е спряно Това е най-добрият избор за мнозина. Тази конфигурация е идентична с предишната, с изключение на това, че ако ръчно спрете контейнера за поддръжка, Докер няма да се опита да го включи. автоматично след рестартиране на сървъра, като се спазва вашето ръчно решение.
За тези, които искат да действат само в отговор на критични повреди, има при повредаТази политика задейства рестартиране само ако контейнерът завърши с ненулев код за изход. Можете дори да ограничите това, като добавите максимален брой повторни опити, предотвратявайки влизането на системата в безкраен цикъл на рестартиране, ако грешката е постоянна и критична.
Автоматизация за „нездравословни“ контейнери
Тук нещата стават интересни. Понякога контейнерът все още се показва като „Включен“, но състоянието му е... нездравословен защото не преминава вътрешни проверки. Предишните политики са неефективни тук, тъй като процесът технически не е мъртъв. За да разрешим това, можем да приложим директивата ПРОВЕРКА НА ЗДРАВЕТО в Dockerfile или във Docker Compose файла, дефиниране на команда (като например curl към конкретен порт), за да проверите дали приложението отговаря.
След като настроим проверката на състоянието, можем да създадем Баш скрипт който се изпълнява на всеки няколко минути, използвайки crontab от Linux. Този скрипт трябва да филтрира контейнери, които са в състояние unhealthy или тези, които са излезли с код за грешка 128 и са изпълнили docker restart за тях.
За да работи това гладко и да се рестартира автоматично Docker контейнер, е важно потребителят, изпълняващ cron задачата, да има необходимите разрешения. необходимите разрешения в групата на DockerПо този начин системата следи средата на всеки 5 или 10 минути и активира всяка услуга, която е станала „зомби“, гарантирайки почти пълна наличност без човешка намеса.
Разширена интеграция със systemd
Когато работите в по-професионална среда, може да искате контейнерите ви да се държат така оригинални Linux услугиИнтегриране Докер Systemd ви позволява да управлявате сложни зависимости, като например да гарантирате, че базата данни стартира преди уеб приложението. Това се постига чрез създаване на файлове .service в маршрута /etc/systemd/system/.
Можем да проектираме последователност на включване и изключване на захранването Контролирано. С помощта на персонализирани скриптове, свързани със systemd, е възможно да се спрат контейнери в обратен ред на техните зависимости, за да се предотврати повреда на данните. Използвайки типа oneshot и конфигуриране на targets подходящ (като например multi-user.target o shutdown.target), сървърът обработва целия жизнен цикъл на контейнера.
Друга мощна опция за автоматично рестартиране на Docker контейнер, когато той спре да отговаря, е използването на флага --rm в комбинация със systemd. Това позволява контейнерът да бъде премахнат при спиране и да бъде създаден нов от базовия образ при стартиране, като се гарантира, че Състоянието на контейнера трябва винаги да бъде чисто и непроменено.делегиране на съхранението на данни единствено на външни томове.
Външни инструменти и съвременни алтернативи
Ако не искате да се занимавате с писане на Bash скриптове, има инструменти на трети страни. Има приложения с отворен код, специално проектирани за рестартиране на контейнери въз основа на... установен графикТова е много полезно за повтарящи се задачи, като например подновяване на SSL сертификати. По същия начин, инструменти като Време на работа Кума Те ви позволяват да следите състоянието на услугите от визуално табло и да изпращате известия до Telegram или Gotify, ако нещо се обърка. Всички те са много полезни за автоматично рестартиране на Docker контейнер, когато той спре да отговаря.
За тези, които търсят по-лека или естествена алтернатива, Подман Това е превъзходен вариант. Благодарение на архитектурата си без демони и функционалността на КвадлетПозволява ви да създавате прости декларативни файлове, които systemd автоматично преобразува в оптимизирани услуги, предлагайки много по-органична интеграция от традиционния Docker.
Пълният контрол върху жизнения цикъл на вашите услуги включва комбиниране на използването на правила за рестартиране, постоянно наблюдение чрез здравни проверки и, в по-сложни случаи, подкрепата на systemd или инструменти за мониторинг така че вашата инфраструктура да е стабилна и да не зависи от това някой да се сеща ръчно да рестартира сървъра всяка седмица.
Редактор, специализиран в областта на технологиите и интернет, с повече от десет години опит в различни цифрови медии. Работил съм като редактор и създател на съдържание за компании за електронна търговия, комуникации, онлайн маркетинг и реклама. Писал съм и на уебсайтове за икономика, финанси и други сектори. Работата ми е и моя страст. Сега, чрез моите статии в Tecnobits, опитвам се да изследвам всички новини и нови възможности, които светът на технологиите ни предлага всеки ден, за да подобрим живота си.