Измените статус докера на «Выход», т. Е. Отключите контейнер при внутренней проверке процесса.

Question

У меня есть докер-контейнер, который запускает пользовательский php-файл или, скажем, скрипт оболочки unix.

Если сценарий выполняется нормально, контейнер докера должен продолжить выполнение RUN, однако, если сценарий завершается ошибкой из-за ошибки или из-за пользовательской проверки; затем я хочу прекратить (остановить), т. е. изменить статус этого контейнера Docker на «Выход».

Пример 1: сценарий оболочки Unix периодически проверяет определенный файл или данные в файловой системе / URL. Если эти данные / файл не найдены, я бы хотел, чтобы контейнер Docker был отключен (состояние выхода), иначе он должен продолжать работать.

Пример 2: скрипт запускается и проверяет количество застрявших потоков для другого процесса. Если число застрявших потоков больше 5, я бы хотел, чтобы процесс докера был остановлен (состояние выхода), иначе он должен продолжать работать.

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

Можете ли вы предложить?

Answer 1

Каждый контейнер Docker имеет некоторый основной процесс, независимо от того, был ли он запущен как ENTRYPOINT или CMD.Этот процесс имеет pid 1, с правами и обязанностями, которые влечет за собой.Время жизни контейнера точно соответствует длине этого основного процесса: единственный способ заставить контейнер выйти, это заставить pid 1 выйти.Поскольку pid 1 особенный, может не работать до kill 1.

Если бы я собирался реализовать это, я бы написал программу (вероятно, на C), которая могла бы выполнятьпроверка работоспособности и запуск основного процесса.Если процесс завершится нормально, супервизор подождет (2) и затем выйдет сам, вызывая выход контейнера.Если проверка работоспособности не удалась, супервизор убил бы (2) своего потомка, подождал бы (2) и затем сам вышел бы.

Я несразу же узнают о готовой реализации этой концепции.Он не отличается от того, что делает supervisord , за исключением того, что supervisor ожидает запуск в качестве процесса инициализации, который никогда не завершается.

Еще одна возможность - реализовать проверки работоспособности в самом приложении.Затем вы просто запускаете один процесс, и если проверка работоспособности завершается неудачно, он может убить себя (например, exit (3)).У высокоуровневых оркестраторов, таких как Kubernetes, также есть концепция проверки работоспособности, которая может быть привязана к сетевому запросу или команде, которая выполняется внутри контейнера (для Kubernetes см. Пробники контейнеров ).