Детальный разбор конфигурации
Документация по конфигурации gitlab runner в toml подробно объясняет все значения конфигурации, я кратко опишу только то, что использовал в нашем случае.
check_interval = 0 — Интервал времени в секундах для проверки раннером новых jobs. Иными словами как часто runner будет стучаться на gitlab с вопросом “есть ли для меня работа?”. Так как у нас 0, будет использовать значение по умолчанию (3 секунды).
concurrent = 1 — Лимит на кол-во параллельных jobs. Мы можем установить его внутри секции отдельного раннера что бы применить лимит на конкретный раннер. Так как мы указали значения в корне конфигурации, а не для отдельного раннера — мы установили глобальное ограничение для всех раннеров, на случай если их в будущем будет несколько, пока что у нас только 1.
url = "https://gitlab.com/" — Тут нужен URL Gitlab, если у вас self-hosted Gitlab, то нужен ваш адрес. Мы же используем Gitlab.com (SaaS-инстанс) по этому просто глобальный
https://gitlab.com к которому наш раннер будет подключаться.
token = ВАШ_РАННЕР_ТОКЕН_ИЗ_НАСТРОЕК_GITLAB — сюда мы скопировали токен из настроек Gitlab (на последнем скриншоте действие 5).
executor = docker — Мы уже разобрали тему экзекьютеров выше, наш выбор Docker.
image = "alpine:3.22.4" — Образ по умолчанию который будет использован для всех джобов. Используем alpine — самая легковесная linux версия. На всякий случай конкретная версия, а не
latest — так меньше вероятность что в какой-то момент что-то перестанет работать, в ранее работающих конфигурациях.
privileged = false — Это привилегированный режим запуска контейнеров. В обычном докере контейнер в привилегированном режиме запускается так:
docker run --privileged alpine:3.22.4, в
docker-compose.yml у сервиса ставиться флаг
privileged: true. Что бы понимать все особенности этого режима, нужно хорошо ориентироваться в системе контроля доступов linux, об этом у меня есть
статья на Хабре. Если совсем коротко, privileged:
- Включает все capabilities (привилегии) ядра Linux — речь о механизме ограничения отдельных низкоуровневых операций процессов. Например, управление сетевыми настройками, но не уровне изменения какого нибудь etc/network/interfaces, а напрямую на уровне операций, которые процесс может попросить выполнить ядро линукса (включить, отключить интерфейс, изменить MAC адресс и тд).
- Отключает стандартный профиль secure computing mode (seccomp) — механизм безопасности ядра, ограничивающий системные вызовы (syscalls). Примеры syscalls это: reboot, mount, open, read, write и т.д.
- Отключает AppArmor.
- Отключает метку процесса SELinux (Security-Enhanced Linux).
- Предоставляет доступ ко всем устройствам хоста.
- Делает виртуальную файловую систему (sysfs) доступной для чтения и записи.
- Делает монтирования cgroups доступными для чтения и записи.
Думаю, сложилось понимание, что с привилегированным режимом нужно быть очень осторожным.
disable_entrypoint_overwrite = false — если здесь true, то нельзя переопределять entrypoint контейнеру из
.gitlab-ci.yml. В shared runner стоит true, что ограничивает возможности в целях безопасности. Про
entrypoint хорошо
описано здесь. Кому интересно можете отследить появление этой фичи:
MR c добавлением флага.
disable_cache = false — Данная опция сохраняет возможность использовать cache, который указывается в
.gitlab-ci.yml. Этот кэш позволяет расшаривать данные между джобами. Например:
# Использование кэша в .gitlab-ci.yml
cache:
paths:
- node_modules/
- .m2/repository/
- .pip-cache/
Кэш может работать через Docker volume или S3. Docker volume не имеет смысла в shared runners, так как там все джобы создаются в виртуалках и полностью изолированы друг от друга. В нашем случае — self-hosted runner, и мы можем использовать кэш для ускорения работы пайплайнов. Но стоит быть аккуратным и осознанно использовать кэш: без тонкого понимания жизненного цикла кэша можно создать трудноуловимые баги. Более совершенная реализация кэша — через S3. Подробнее:
Advanced configuration/ the [runners.cache] section.
