Зачем в докере докер?

нафига?

such as development of Docker itself

Что тебе здесь не нравится?

Есть ещё KinD, применение похожее: разработка, тестирование, обучение.

Ехал докер через докер. Докер докер докер докер.

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

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

одинокий докер пал, докер в докере пал но хостящий докер воскресит павшего , докеру в докере в докере же не бывати!

А докер внутри докера внутри докера уже пробовали запустить? И на каком уровне вложенности оно поломаться должно?

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

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

Чтобы собирать докер образы внутри докер контейнера, например. Обычный случай, если у тебя ci и его задачи выполняются в докер контейнерах.

«На докере сидит и докером погоняет» 😀

Основная задача, которая решается - это изоляция окружения, по факту тот кто может запускать контейнеры на хосте, через монтирование может получить доступ, допустим к /etc/shadow. При запуске dind и пробросе его в нужный тебе контейнер или запуск контейнера в контексте dind, ты не сможешь получить доступ к хосту. Плюсом можно ограничить сетевой доступ, так как тебе нужно. И при том ты получишь повторяемость и изоляцию. Допустим многие в CI любят под конец таски вызывать docker system prune –all –force, что может удалить только что собраный образ из соседнего пайплайна. Это один из понятных примеров.

Короче для систем, где есть больше одного пользователя, это обязательная вещь.

чтобы в гитлабе собирать образы и пулять их в локальное хранилище

Там какие-то опасные привилегии надо выписывать, поэтому нет, не разворачивал. А нафига - это когда какая-то автоматизация крутится уже в докере, и она должна запускать новые контейнеры (базу данных под тесты например). Хорошего способа это сделать нет, все способы по-своему плохие, и dind это всего лишь один из вариантов.

Бывают приложения, которые по задумке запускаются как контейнер и ходят в хостовый docker.sock, чтобы что-то запускать-оркестрировать

Ну и уже упоминали сборку образов в CI, где часто раннеры крутятся в контейнерах. Хотя тут можно выкрутиться, например использованием kaniko вместо условного docker build

Наверно можно одно со вторым совместить, и получить докер внутри докера - внутри докера

Ни на каком, оно же в ядре пацаны нормально сделали

На докере сидит и докером погоняет

В семи докерах сервис без сбора метрик.

Штука полезная если тебе нужно выполнить какую-то задачу в контейнере в кластере Swarm и по результатам задачи - перезапустить другой контейнер. Прокидываешь docker socket (а лучше - используешь socket proxy) и запускаешь команду docker в контейнере.

Но да, для непосвященного выглядит как ехал докер через докер :-)

Ну кайнд это ж кубы в одном контейнере, это другое :)

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

dind это именно запуск докера в докере. Если storage driver overlay2 для внутреннего докера, то разницы в целом не будет по скорости работы по сравнению с тем же dood. Ну и собираемые внутри контейнера докер образы не попадают на основную систему, что тоже плюс.

в раннерах гитлаба гонять, например.