Comments 6

О, здорово!
Вообще полностью согласен с тем, что сборочные пайплайны хорошо ложатся на докер. Это факт. Переносимость. Повторяемость. Насколько это вообще возможно.
DinD — полностью согласен, что лучше, чем проброс демона с хост машины. Почему? Потому что проброс сокета — это натуральный рут-доступ к хостовой машине. Помимо проблем с накоплением временных образов и прочих докеровских сущностей. Я уж не говорю о ситуации, когда нужно пайплайны крутить конкурентно (параллельно). Можно исхитриться и нарезать каждый раз новую сеть, новый набор образов и контейнеров с уникальными названиями, но так себе решение. DinD тут реально помогает. Но у него есть и недостатки. Первый — мы не можем задействовать кэш образов. При каждом пересоздании DinD контейнера он будет обнуляться. С другой стороны это же и являетя преимуществом, т.к. каждый раз мы получаем "чистую" среду. Второй недостаток заключается в производительности. В первую очередь — при работе с файлами. overlay поверх overlay реально тормозит. Другой вопрос, что это не всегда существенно. Можете почитать классическую статью от 2015 года почему DinD — плохо — https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ и сделать свои выводы.


Также я не понял две вещи:


  1. запускать докер-демон в фоне, если можно отдельно запустить контейнер с демоном dind, а потом к нему прилинковать контейнер с docker-клиентом, да хоть с хост машины можно ходить в контейнер dind. Так по сути пайплайны gitlab и работают. https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#making-docker-in-docker-builds-faster-with-docker-layer-caching
  2. зачем собирать свой кастомный dind образ (а его еще придется поддерживать!!!!), если есть вполне официальный docker:dind, а если он не очень — то есть от гитлаба свой.

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

Проект изначально задумывался как чисто академический. Я его использую в своих пайплайнах и пока доволен, переходить на что-то другое, думаю пока рановато. Буду развивать дальше. Статью Jpetazzo читал и давно подписан на него на GitHub-е. Есть одно, но — статья довольно старая и проблему с байндингом директорий вложенных контейнеров можно решить. Думаю написать об этом следующую большую статью.
Вы сами ответили на свой вопрос: поднимать контейнер с докер демоном в фоне, а потом к нему еще и контейнер с клиентом — выглядит довольно громоздко.

docker-compose решает эти проблемы.
Если же есть параллельные билды, то можно использовать lxc + docker-compose, как это делает circleci.

docker-compose решает эти проблемы.

не решает.


Если же есть параллельные билды, то можно использовать lxc + docker-compose, как это делает circleci.

можно.

Only those users with full accounts are able to leave comments. Log in, please.