Каков результат монтирования `/ var / run / docker .sock` в сценарии Docker в Docker?

Question

Я читал Может ли кто-нибудь объяснить docker .sock , чтобы понять, что делает /var/run/docker.sock, но его использование в GitLab CI Использование Docker привязки сокета сбило меня с толку .

Вот их пример команды для gitlab-runner регистрации:

sudo gitlab-runner register -n \
  --url https://gitlab.com/ \
  --registration-token REGISTRATION_TOKEN \
  --executor docker \
  --description "My Docker Runner" \
  --docker-image "docker:19.03.12" \
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock

Я вижу два места, откуда полученный контейнер может получить docker.

1. Сокет unix /var/run/docker.sock.
2. Бинарный файл docker, включенный в базовый образ docker:19.03.12.

Разве это не конфликт PATH? Я думал, что это должно быть одно или другое, где я получаю возможность использовать docker либо из сокета unix хоста, либо из базового образа.

Я бы подумал, что --docker-image должно быть ubuntu:latest или что-то в этом роде, которое не идет с docker, поскольку PATH s docker уже будет приходить из сокета хоста. В качестве альтернативы можно удалить крепление для гнезда docker.

Что на самом деле происходит здесь в отношении этого двойного включения docker?

Answer 1

Файл Unix сокета /var/run/docker.sock обычно создается демоном Docker. Если вы запустите что-то еще в качестве основного процесса контейнера, сокет не будет создан. Вы можете напрямую посмотреть, запустив контейнер с основным процессом, отличным от Docker, например /bin/ls:

docker run --rm docker:19.03.12 ls -l /var/run
docker run --rm docker:19.03.12 ls -l /run

Двоичный файл /usr/bin/docker должен существовать в файловой системе контейнера, если вы собираетесь используй это. Контейнеры никогда не могут вызывать двоичные файлы, находящиеся на хосте, и API сокетов также не будет создавать двоичные файлы. (Некоторые из самых ранних постов «использовать сокет хоста Docker» защищали привязку двоичного файла к контейнеру, но это приводит к проблемам с зависимостями библиотеки и делает изображения не самодостаточными.)

Итак, если все, что вам действительно нужно, это контейнер Docker с двоичным файлом docker, который может вызывать сокет Docker хоста, вам понадобится изображение типа docker, где изображение имеет /usr/bin/docker, плюс вам нужно привязать /var/run/docker.sock хоста к контейнеру.

docker run \
  --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  docker:19.03.12 \
  docker ps

Настройка GitLab, на которую вы ссылаетесь, кажется довольно надуманной. Использование образа docker для запуска заданий означает, что в значительной степени функция only , которую может выполнить шаг сборки, - это команда docker. На техническом уровне вы не можете запустить контейнер docker, не имея уже двоичного файла docker и доступа к работающему демону Docker; подход оболочки-исполнителя, описанный в верхней части этой страницы, кажется более простым, и на самом деле у него нет никаких недостатков.

Вы также можете найти Docker изображение зависимостей времени сборки (компиляторы, файлы заголовков, средства проверки c, ...). Это позволит вам обновить эти зависимости без необходимости развертывать обновление для всего кластера сборки. Если ваши сценарии сборки сами должны вызывать docker, тогда ваш образ инструментов сборки должен установить Docker, просто используя обычную команду RUN apt-get install. Таким же образом вам необходимо подключить sh сокет хоста Docker к контейнеру, поэтому вам не нужно запускать отдельный демон Docker.

Answer 2

Прежде всего вам нужно понять, как работает docker, чтобы понять этот поток, docker имеет сервер и клиент docker-cli и docker daemon клиент взаимодействует с демоном docker, используя APIS.

docker.sock - это сокет UNIX, который обеспечивает соединение между клиентом docker и демоном (сервером).

Так как контейнер docker в отличие от виртуальной машины don не иметь kernel, каждый контейнер, запущенный в docker, использует ядро ​​хоста и строит контейнер поверх ядра хоста. у контейнера нет самого ядра, поэтому вы не можете построить docker внутри docker, если не используете ядро ​​хоста.

gitlab-runner имеет много исполнителей: shell ssh docker et c ...

с использованием Executer docker означает, что бегун создаст контейнер, а затем клонирует ваше репо внутри этого контейнера и запустит переданные вами скрипты, а затем уничтожит этот контейнер.

gitlan-runner нужен базовый образ, чтобы создать контейнер, который будет запускать скрипты. вам не нужно использовать docker:19.03.12 или монтировать /var/run/docker.sock том, если в вашем скрипте нет команд docker (или в целом вам нужен доступ к docker), и обе стратегии отличаются, вы должны знать, что установка docker.sock не является docker в docker.

для достижения docker в docker вам нужно добавить флаг --privileged к контейнеру, который в основном составляет root в вашем контейнере должно быть полное root на хосте. он может управлять параметрами ядра, у него есть все возможности.

вот хорошая справочная по этой теме