Насколько критичен тупой init для Docker?

Question

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

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

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

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

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

Answer 1

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

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

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

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