Вопрос или проблема
В последний раз я использовал Docker в Docker для runners, но это требует привилегированного режима
Файл compose:
version: '3.7'
services:
runner:
image: gitlab/gitlab-runner:latest
volumes:
- ./config:/etc/gitlab-runner
- ./run:/var/run/
# - /var/run/docker.sock:/var/run/docker.sock
docker:
image: docker:dind
restart: always
privileged: true # <-- проблемы с безопасностью
volumes:
- ./run:/var/run/
У меня есть персональный компьютер. У меня есть команда Gitlab, которая нуждается в запуске docker build
или docker-compose up
скриптов с помощью Gitlab CI. Я действительно хочу ускорить CI. Поэтому я делюсь своим хостовым Docker с runners, теперь у них есть кеш Docker (образы и так далее), и когда один этап строит образ, а другой его требует, это действительно быстро.
У меня такая же проблема с Jenkins. Мне нужно поделиться хостовым Docker с рабочими узлами.
В последний раз я хотел протестировать новый подход и запустить runners с их собственным Docker. У меня почти нет 2 важных вещей:
– ограничение ресурсов (я хочу предоставить 7 из 8 ядер CPU, 10 из 16 ГБ памяти, некоторые ограничения на HDD)
– безопасность
Важно добавить: у меня нет CI-скриптов, которые требуют GPU, сетевых возможностей, монтирования некоторых устройств и так далее. Обычно они выполняют простые docker build
и docker push
, иногда мне нужно забрать артефакты с помощью docker cp
, и это всё.
Основной вопрос: как запустить Docker в Docker без прав root на хост-машине?
Оба – совместное использование сокетов или привилегированный режим создают уязвимости для хост-машин, а наличие виртуальной машины (например, VirtualBox или что-то подобное) медленно и трудно осуществить, также я хочу делиться ресурсами и хочу, чтобы Docker мог использовать 10 из 16 ГБ, но 10 ГБ должны быть свободны, когда они не используются.
У меня есть некоторые неопределенные ошибки от контейнера dind (перед отказом), когда я запускаю его с обычными привилегиями:
gitlab-runner-docker | mount: permission denied (are you root?)
gitlab-runner-docker | mount: permission denied (are you root?)
gitlab-runner-docker | Could not mount /sys/kernel/security.
gitlab-runner-docker | AppArmor detection and --privileged mode might break.
С какими проблемами я столкнусь, если попытаюсь запустить Docker в Docker без привилегированного режима? Как это сделать?
Что касается балансировки нагрузки оперативной памяти, я не могу помочь, но вы можете запустить Docker в Docker (dind) без прав sudo, добавив вашего текущего пользователя в группу docker,
Я не вижу безопасности совместно используемых сокетов, потому что это теряет свою целостность, но я бы рекомендовал инстанцировать dind с параметром компоновщика с привилегированным параметром: true
Ответ или решение
Запуск Docker внутри Docker (DinD) без использования привилегированного режима представляет собой серьезную задачу, особенно если вы хотите обеспечить безопасность и управляемость ресурсов. Привилегированный режим предоставляет контейнеру неограниченный доступ к ресурсам хоста, что может создать уязвимости. Давайте рассмотрим, как можно организовать подобное окружение без использования этого режима, и какие проблемы могут возникнуть.
1. Установка Docker и настройка GitLab Runner
Для начала, вам нужно установить Docker на вашем хосте и убедиться, что ваш пользователь добавлен в группу docker
. Это позволит вашему пользователю выполнять команды Docker без использования sudo
.
sudo usermod -aG docker $USER
После изменения групп необходимо выйти из системы и войти снова, чтобы новые настройки вступили в силу.
2. Использование Docker Socket
Наиболее рекомендуемым подходом к запуску DinD без привилегий является использование монтированного сокета Docker. Это позволит вашему GitLab Runner запускать Docker-контейнеры, используя Docker хоста.
Вместо использования отдельного сервиса docker
, вы можете модифицировать ваш docker-compose.yml
, чтобы монтировать сокет Docker напрямую в контейнер GitLab Runner. Вот как это можно сделать:
version: '3.7'
services:
runner:
image: gitlab/gitlab-runner:latest
volumes:
- ./config:/etc/gitlab-runner
- /var/run/docker.sock:/var/run/docker.sock # Монтируем сокет хоста
3. Ограничение ресурсов
Чтобы контролировать использование ресурсов (ЦП и ОЗУ) контейнерами GitLab Runner, вы можете настроить ограничения в соответствующих конфигурациях. Однако ограничения ресурсов следует устанавливать в GitLab CI/CD pipeline.
Пример .gitlab-ci.yml
конфигурации с ограничениями ресурсов:
job:
script:
- echo "Running a Docker job"
tags:
- docker
resource_group: my-resource-group
limits:
memory: 10Gi
cpu: "7"
4. Решение проблем с безопасностью
Монтаж сокета Docker предоставляет больше возможностей, но он также требует осторожного обращения. Убедитесь, что доступ к вашему GitLab Runner имеет только авторизованный персонал, чтобы избежать несанкционированного доступа к Docker хосту.
- Аудит безопасности: Регулярно проверяйте и аудируйте доступ к вашим контейнерам и конфигурациям.
- Изоляция окружений: Используйте различные ресурсы (например, разные сетевые пространства, имена хостов), чтобы изолировать задачи, которые могут потенциально конфликтовать.
5. Проблемы, с которыми можно столкнуться
При запуске Docker в Docker без привилегий могут возникнуть следующие проблемы:
- Недостаток привилегий: Некоторые функциональные возможности, такие как монтирование определенных файловых систем или использование сетевых пространств, могут быть недоступны. Это может привести к ошибкам, таким как "permission denied".
- Ограниченные возможности: Возможно, вам придется адаптировать ваши CI/CD скрипты, чтобы они работали в более ограниченной среде.
- Проблемы с совместимостью: Обновления либо изменения конфигураций в вашем контейнере GitLab Runner могут привести к несовместимостям с используемым образом Docker.
Заключение
Для реализации Docker в Docker без привилегий рекомендуется монтировать сокет Docker с хоста и установить подходящие ограничения ресурсов через конфигурацию GitLab CI. Хотя это может потенциально ослабить уровни безопасности, правильная настройка и мониторинг могут помочь минимизировать риски. Важно оставаться внимательными к безопасному управлению и настройке вашего CI/CD процесса.