Роль докеры в докере (dind) в gitlab ci

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

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

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

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

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

Почему клиент-докер и демон-докер не могут находиться в одном и том же контейнере (активирован)

Ответ 1

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

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

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

зачем нужен сервис и образ докера […]?

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

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

Ответ 2

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