Роль службы 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 нуждается в этом.