Роль службы 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 buildwhithin работа ci? неdocker:latestизображение (в рамках которого задание будет выполнено!) включить демон docker (и я думаю, чтоdocker-composeтакже), которые являются инструментами, необходимыми для команд, которые нам нужны (например,docker build,docker pushetc)?
если я не ошибаюсь, вопрос более или менее становится:
почему клиент 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 нуждается в этом.