Обеспечение работы контейнеров всегда с политикой перезапуска Docker

Получение уведомления о том, что контейнеры Docker не используются, является одним из худших способов провести ночь. В сегодняшней статье мы обсудим, как использовать политику перезапуска Docker для автоматического перезапуска контейнеров и предотвращения таких ночных уведомлений.

Что происходит при сбое приложения?

Прежде чем мы начнем с политики перезапуска Docker, давайте немного разберемся, как Docker ведет себя при сбое приложения. Чтобы облегчить это, мы создадим контейнер Docker, который выполняет простой сценарий bash с именем crash.sh .

Вышеприведенный скрипт прост; при запуске он будет sleep 30 секунд, а затем выйдет с кодом выхода 1 указывающим на ошибку.

Сборка и запуск пользовательского контейнера

Чтобы запустить этот скрипт в контейнере, нам нужно создать собственный контейнер Docker, который включает в crash.sh скрипт crash.sh . Чтобы создать собственный контейнер, нам сначала нужно создать простой Dockerfile .

Dockerfile будет содержать следующие три строки:

Приведенный выше Dockerfile создаст контейнер на основе последней версии ubuntu:14.04 . Он также добавит скрипт crash.sh в каталог / контейнера. Последняя строка сообщает Docker, что нужно запускать скрипт crash.sh при crash.sh контейнера.

Dockerfile , теперь мы можем собрать наш пользовательский контейнер с помощью команды docker build .

Эта команда построения создала образ Docker с testing_restarts именем testing_restarts . Теперь мы можем запустить контейнер, используя образ testing_restarts , выполнив testing_restarts docker run .

Из вышесказанного видно, что Docker смог запустить контейнер с именем testing_restarts . Давайте проверим состояние этого контейнера, запустив docker ps .

Команда docker ps не показывает никаких запущенных контейнеров. Причина этого заключается в том, что docker ps по умолчанию показывает только запущенные контейнеры. Давайте посмотрим на работающие и не работающие контейнеры, используя флаг -a .

С результатами docker ps мы видим, что при выходе из приложения в контейнере Docker этот контейнер также останавливается. Это означает, что по умолчанию, если приложение, работающее в контейнере, аварийно завершает работу, контейнер останавливается, и этот контейнер останется остановленным, пока кто-то или что-то не перезапустит его.

! Новый призыв к действию

Изменение поведения докера по умолчанию

Можно автоматически перезапустить разбитые контейнеры, указав политику перезапуска при запуске контейнера. Чтобы лучше понять политики перезапуска, давайте посмотрим, что происходит, когда мы используем политику перезапуска always с этим же контейнером.

В приведенной выше команде мы указали, что Docker должен применять политику always перезапуска к этому контейнеру с помощью флага --restart . Давайте посмотрим, как это повлияет на наш контейнер, выполнив docker ps снова.

На этот раз мы видим, что контейнер запущен и работает, но только в течение 21 секунды. Если мы снова запустим docker ps , мы увидим что-то интересное.

Второй запуск показывает, что контейнер был только в течение 19 секунд. Это означает, что даже если наше приложение ( crash.sh ) продолжает выходить с ошибкой, Docker постоянно перезапускает контейнер при каждом выходе.

Теперь, когда мы понимаем, как политики перезапуска могут использоваться для изменения поведения Docker по умолчанию, давайте посмотрим, какие политики перезапуска доступны в Docker.

Политика перезапуска докера

В настоящее время Docker имеет четыре политики перезапуска:

• no
• on-failure
• unless-stopped
• always

Политика no является политикой перезапуска по умолчанию и просто не перезапускает контейнер ни при каких обстоятельствах.

Перезапуск при неудаче, но остановка при успехе

Политика on-failure немного интересна, поскольку она позволяет Docker перезапустить контейнер, если код завершения указывает на ошибку, но не если код выхода указывает на успех. Вы также можете указать максимальное количество раз, когда Docker автоматически перезапускает контейнер.

Давайте попробуем эту политику перезапуска с нашим контейнером testing_restarts и установим ограничение в 5 перезапусков.

Если мы запустим docker ps в течение минуты после запуска контейнера, мы увидим, что контейнер запущен и был недавно запущен.

Однако это не будет верно, если мы запустим команду docker ps 3 минуты после запуска контейнера.

Из вышесказанного видно, что через 3 минуты контейнер останавливается. Это связано с тем, что контейнер был перезапущен больше, чем наша настройка max-retries .

С успехом

Преимущество при on-failures состоит в том, что, когда приложение завершает работу с успешным кодом завершения, контейнер не будет перезапущен. Давайте посмотрим на это в действии, сделав небольшое изменение в скрипте crash.sh .

Изменением будет установка кода выхода на 0 .

Установив скрипт для выхода с кодом выхода 0 , мы удалим индикатор ошибки из скрипта. То есть, насколько Docker может сказать, этот скрипт будет успешно выполняться каждый раз.

С измененным сценарием нам нужно будет перестроить контейнер, прежде чем мы сможем запустить его снова.

С восстановлением образа контейнера, давайте снова запустим этот контейнер с теми же настройками при on-failures и max-retries .

На этот раз, когда мы выполняем docker ps -a , мы должны увидеть разные результаты.

Поскольку сценарий crash.sh с успешным кодом выхода ( 0 ), Docker воспринял это как успешное и не перезапустил контейнер.

Всегда перезапускать контейнер

Если мы хотим, чтобы контейнер перезапускался независимо от кода выхода, у нас есть пара политик перезапуска, которые мы могли бы использовать:

• always
• unless-stopped

Политика always перезапуска говорит Docker перезапускать контейнер при любых обстоятельствах. Мы экспериментировали с политикой always перезапуска ранее, но давайте посмотрим, что произойдет, когда мы перезапустим текущий контейнер с политикой always перезапуска.

Если мы подождем несколько минут и снова запустим docker ps -a , мы увидим, что контейнер был перезапущен даже после успешного завершения кода завершения.

Что хорошо в политике always перезапуска, так это то, что даже если наш хост Docker потерпит крах при загрузке, служба Docker перезапустит наш контейнер. Давайте посмотрим на это в действии, чтобы полностью оценить, почему это полезно.

По умолчанию или даже при on-failures наш контейнер не будет работать при перезагрузке. Что, в зависимости от того, какую задачу выполняет контейнер, может быть проблематичным.

С политикой always перезапуска это не так. Политика always перезапуска всегда перезапускает контейнер. Это верно, даже если контейнер был остановлен перед перезагрузкой. Давайте посмотрим на этот сценарий в действии.

Перед перезагрузкой нашей системы мы просто остановили контейнер. Это означает, что контейнер все еще там, но не работает. Однако после перезагрузки системы контейнер будет работать.

Причиной запуска нашего контейнера после перезагрузки является политика always . При каждом перезапуске службы Docker контейнеры, использующие политику always будут перезапущены независимо от того, были они запущены или сейчас.

Проблема в том, что перезапуск контейнера, который был ранее остановлен после перезагрузки, может быть немного проблематичным. Что если наш контейнер был остановлен по уважительной причине или, что еще хуже, что если контейнер устарел?

Решением для этого является политика перезапуска без unless-stopped .

Останавливаться только когда остановлен Docker

Политика перезапуска без остановок ведет себя так же, как и always с одним исключением. Когда контейнер останавливается и сервер перезагружается или перезапускается служба Docker, контейнер перезапускаться не будет.

Давайте посмотрим на это в действии, запустив контейнер с политикой unless-stopped и повторив наш последний пример.

Запустив контейнер, давайте остановим его и снова перезагрузим систему.

На этот раз, когда система перезапустится, мы должны увидеть, что контейнер находится в остановленном состоянии.

Один из важных моментов с параметром » unless-stopped заключается в том, что, если контейнер работал до перезагрузки, он будет перезапущен после перезапуска системы. Мы можем увидеть это в действии, перезапустив наш контейнер и перезагрузив систему снова.

После этой перезагрузки контейнер должен работать.

Разница между always и unless-stopped может быть небольшой, но в некоторых средах это небольшое различие может быть критическим решением.

Выбор лучшей политики перезапуска

При выборе наилучшей политики перезапуска важно помнить, какой тип рабочей нагрузки выполняет контейнер.

Например, экземпляр Redis может быть критическим компонентом в вашей среде, который должен иметь политику always или unless-stopped . С другой стороны, приложение пакетной обработки может нуждаться в перезапуске до успешного завершения процесса. В этом случае имеет смысл использовать политику при on-failures .

В любом случае, с помощью политики перезапуска Docker вы можете быть уверены, что в следующий раз, когда хост Docker загадочно перезагрузится в 3 часа ночи, ваши контейнеры будут перезапущены.

Ссылка:

Обеспечение того, чтобы контейнеры всегда выполнялись с политикой перезапуска Docker от нашего партнера JCG Бена Кейна в блоге Codeship Blog .