Runner и контейнерная среда

Курс «Лаборатория GitLab CI/CD»

Jobs лаборатории course-card объявляют образ node:24-bookworm-slim, но этот образ не выполняется внутри страницы GitLab. Работу получает runner, а способ исполнения определяет executor. Разберём эту цепочку, чтобы отличать ожидание исполнителя от ошибки программы и понимать, почему один YAML может вести себя по-разному в разных средах.

Практический результат урока — паспорт подходящей среды для нашего конвейера. Регистрацию или установку runner здесь не выполняем. Не требуются AWS EC2, Docker-in-Docker, привилегированный режим и сборка собственных образов. Эти темы встречаются в старых демонстрациях, но для встроенных программ Node.js они добавили бы отдельные права и инфраструктуру без необходимости.

Runner получает job

GitLab хранит конфигурацию и координирует работу. Runner связывается с GitLab, получает доступное задание, подготавливает окружение, получает исходники и артефакты, выполняет script, затем загружает предусмотренные outputs. Для каждого шага есть собственные причины ошибки. Если job ещё pending, наша программа может вообще не начинать работу.

Executor определяет способ выполнения. Shell исполняет команды в среде машины runner. Docker создаёт контейнер из объявленного образа. Kubernetes использует свою модель окружения. Для course-card будем ориентироваться на Docker executor, чтобы команды Node.js выполнялись в понятном контейнерном семействе, а не зависели от случайной версии на общей машине.

Уровень	Назначение	Пример лаборатории
GitLab	Составить и координировать pipeline	Workflow, jobs и состояние
Runner	Принять и выполнить job	Получить исходники и сохранить outputs
Executor	Подготовить способ выполнения	Docker container
Job image	Предоставить программы внутри среды	Node.js 24

Образ job и образ самого runner — разные вещи. Приложение GitLab Runner может работать в собственном контейнере, но это не означает, что внутри него уже есть нужная версия Node.js для каждой работы. Docker executor создаёт среду job из указанного image. Такая граница помогает объяснить сообщения о загрузке образа до начала script.

Совместимость и tags

У подходящего runner должны быть доступ к проекту и необходимые tags. Если job требует tag, которого нет у доступных исполнителей, он останется в ожидании. Если runner не принимает untagged jobs, конфигурация без tags также может не стартовать. В нашей основной лаборатории tags не заданы: их добавляет владелец учебной инфраструктуры, если процесс требует конкретного исполнителя.

Не указывайте вымышленный tag docker с ожиданием, что GitLab создаст соответствующий runner автоматически. Tags — метки выбора уже доступной инфраструктуры. Для паспорта запишите: кто обслуживает runner, для каких проектов он доступен, как выбираются jobs и какая версия поддерживается вместе с сервером GitLab. Эти сведения находятся вне исходного JavaScript, но влияют на исполнение.

Версии GitLab Runner и GitLab должны быть совместимы. Не применяйте случайный старый runner к новому серверу только потому, что он когда-то выполнял похожую команду. Подробности регистрации и требований приведены в документации Runner. Наша серия описывает текущую модель по документам, доступным 11 октября 2026 года.

Современная регистрация

В актуальном процессе runner сначала создаётся в подходящем контексте GitLab, затем используется runner authentication token. В отличие от старых примеров с registration token, неинтерактивная команда использует --token. Сам токен не приводим в тексте и не помещаем в архив. Следующий листинг показывает только форму действия для администратора собственного учебного runner.

gitlab-runner register \
  --non-interactive \
  --url 'https://gitlab.example.test' \
  --token "$LAB_RUNNER_TOKEN" \
  --executor docker \
  --docker-image node:24-bookworm-slim

Адрес gitlab.example.test является примером, а не действующим сервером. Команду нельзя выполнить буквально без реальной разрешённой среды. Параметры доступа, tags и защиты назначаются в соответствующей модели создания runner. Не переносите все legacy-флаги из старого видео с ожиданием, что они продолжают управлять теми же настройками.

Authentication token связывает приложение Runner с GitLab и является чувствительным значением. Его не нужно передавать как переменную обычного build job. Сам build получает другие доступы, предусмотренные системой исполнения. Разделение токена runner и конфигурации сайта важно для того, чтобы каждый job не становился способом управлять всей инфраструктурой.

Изоляция имеет границы

Docker executor помогает получить отдельную файловую среду, но не делает любой код безусловно безопасным. Важны настройки privileged, mounts, доступ к Docker socket и сеть. Если job получает сокет Docker хоста, возможности могут выходить далеко за рамки своей папки. Для генерации HTML это не требуется и не должно добавляться ради удобства.

В course-card нет команды docker build и нет push в registry. Мы используем готовую среду Node.js, а итоговым продуктом остаётся статический артефакт. Сборка контейнерного приложения является отдельной задачей с собственными входами, правами и проверками. Подробные свойства Docker executor перечислены в официальной документации.

Тег образа может обновляться. Если нужна строгая воспроизводимость, выберите проверенный digest и зафиксируйте его в конфигурации, затем поддерживайте обновления осознанно. Нельзя придумать digest в учебном тексте: он должен соответствовать реальному образу. Поэтому архив использует объявленный тег и прямо сохраняет ограничение, что образ не закреплён по неизменяемому хэшу.

Сохраните отдельно список того, что образ предоставляет и чего в нём нет. Node.js доступен для наших встроенных модулей, но наличие тега node не обещает любые системные утилиты, браузер или Docker daemon. Если будущий шаг требует другую программу, её наличие должно стать явным входом среды. Не расширяйте shell-команду случайными установками в каждом job, пока не определён воспроизводимый способ подготовки окружения. Для текущего каталога такие зависимости отсутствуют. Это позволяет разбирать механизм CI без дополнительных причин сетевой ошибки и сохраняет небольшой паспорт исполняющей среды.

Диагностика среды

Если программа сообщает node: not found, проверьте executor и image, а не число уроков в JSON. Если образ не загружается, script ещё не мог проверить каталог. Если артефакт не скачался, причиной может быть доступность файла или зависимости. Разбор по фазам позволяет не менять рабочий JavaScript из-за ошибки инфраструктуры.

В паспорте нашего runner достаточно записать Docker executor без privileged, доступный образ Node.js 24, возможность загрузки артефактов и отсутствие внешних секретов. Желаемая изоляция должна быть подтверждена владельцем среды при самостоятельной настройке. При подготовке серии установка, регистрация и контейнеры не запускались.

После урока можем объяснить, где выполняются jobs и какие ограничения у выбранной среды. Конфигурация сайта не приобретает внешние права автоматически. Следующий шаг добавит ручную подготовку staging внутри job, сохранив этот ограниченный договор и тот же проверенный артефакт.