Роль службы docker-in-docker (dind) в GitLab ci

по словам чиновника документация gitlab один из способов включить docker build внутри ci конвейеры, чтобы использовать dind сервис (в плане gitlab-ci услуги).

однако, как это всегда бывает с заданиями ci, запущенными на исполнителях docker,docker:latest изображение также необходимо.

может кто-нибудь объяснить:

  • в чем разница между docker:dind и docker:latest образы?
  • (самое главное): почему are и служба и Докер изображение необходимо (например, как указано , связанный с документацией github) для выполнения, например, a docker build whithin работа ci? не docker:latest изображение (в рамках которого задание будет выполнено!) включить демон docker (и я думаю, что docker-compose также), которые являются инструментами, необходимыми для команд, которые нам нужны (например,docker build, docker push etc)?

если я не ошибаюсь, вопрос более или менее становится:

почему клиент docker и демон docker не могут находиться в одном контейнере docker (включен)

2 ответов


в чем разница между docker: dind и docker: последние изображения?

  • docker:latest содержит все необходимое для подключения к демону docker, т. е. для запуска docker build, docker run и такие. Он также содержит демон docker, но он не запускается как его entrypoint.
  • docker:dind строит на docker:latest и запускает демон docker в качестве точки входа.

так, их содержание почти то же самое, но через их entrypoints один настроен для подключения к tcp://docker:2375 как клиент, в то время как другой предназначен для использования для демона.

зачем нужны как сервис, так и изображение docker [...]?

вам не нужны обе. Вы можете просто использовать любой из двух, старт dockerd в качестве первого шага, а затем запустите свой docker build и docker run команды, как обычно, как я сделал здесь; по-видимому, это был оригинал подход в гитлаб в какой-то момент. Но я считаю, что чище просто писать service: docker:dind вместо before_script настройки dockerd. Также вам не нужно выяснять, как начать и установить dockerd правильно в базовом изображении (если вы не используете docker:latest.)

объявив службу в .gitlab-ci.yml также позволяет легко поменять докер-в-докер, если вы знаете, что ваш бегун монтирует его /var/run/docker.sock в свой образ. Вы можете установить защищенный переменная DOCKER_HOST to unix:///var/run/docker.sock чтобы получить более быстрые сборки. Другие, у кого нет доступа к такому бегуну, все равно могут развить ваш репозиторий и вернуться к dind сервис без изменения .giltab-ci.yml.


контейнер будет содержать только вещи, определенные в образе docker. Вы знаете, что можете установить что угодно, начиная с базового образа. Но вы также можете установить Docker (deamon и client) в контейнер, то есть Docker в Docker (dind). Таким образом, контейнер сможет запускать другие контейнеры. Вот почему gitlab нуждается в этом.