Насколько критичен Dumb-init для Docker?

Я надеюсь, что этот вопрос не будет отмечен как primarily opinion-based, но есть объективный ответ на него.

Я прочитал Представляем dumb-init, систему init для контейнеров Docker, в которой подробно описывается, почему и как использовать dumb-init. Честно говоря, для кого-то, кто не слишком разбирается в том, как работает структура процесса Linux, это звучит довольно драматично - и кажется, что вы делаете все совершенно неправильно, если не используете dumb-init.

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

  • В качестве примера возьмем mongo: они непосредственно звонят mongod.
  • В качестве примера возьмем postgres: они напрямую вызывают postgres.
  • В качестве примера возьмем node: они непосредственно звонят node.
  • ...

Если dumb-init имеет значение , поэтому - почему, по-видимому, никто не использует его? Что мне здесь не хватает?

Ответы

Ответ 1

Что-то вроде dumb-init или tini может быть использован, если у вас есть процесс, который порождает новые процессы, и у вас нет хороших обработчиков сигналов, реализованных для обнаружения дочерних сигналов и остановки вашего ребенка, если ваш процесс должен быть остановлен и т.д.

Если ваш процесс не порождает новые процессы (например, Node.js), это может быть необязательно.

Я предполагаю, что MongoDB, PostgreSQL,... которые могут запускать дочерние процессы, имеют хорошие обработчики сигналов. В противном случае были бы процессы зомби, и кто-то задал проблему, чтобы исправить это.

Только проблема может быть официальными языковыми изображениями, такими как node, ruby, golang. У них нет дум-init/tini в нем, как вам обычно не нужны. Но это зависит от разработчика, который может реализовать плохой код для выполнения дочерних программ, чтобы либо исправить обработчики сигналов, либо использовать хелпер в качестве PID 1.