Как работает GitLab Runner?

Принцип работы GitLab Runner

GitLab Runner — это легковесное, кросс-платформенное приложение, которое выполняет задания (jobs) из конвейера CI/CD GitLab и возвращает результаты обратно на сервер GitLab. Это ключевой компонент, превращающий GitLab из системы контроля версий в полноценную платформу DevOps.

Архитектура и основные компоненты

Работу Runner можно разделить на несколько уровней:

1. Координация с GitLab CI/CD: Runner периодически опрашивает сервер GitLab (или получает задания через вебхуки) на наличие новых заданий в конвейере. Для этого используется API GitLab.
2. Исполнитель (Executor): Это "движок", который определяет, где и как будет запущено задание. Runner поддерживает несколько типов исполнителей:

    *   **Shell**: Запускает команды в shell локальной машины, где установлен Runner. Просто, но небезопасно и не изолировано.
    *   **Docker**: Наиболее популярный вариант. Для каждого задания создается изолированный контейнер на основе указанного образа (`image`). Это обеспечивает воспроизводимость и чистоту окружения.
    *   **Docker Machine (autoscaling)**: Позволяет автоматически создавать виртуальные машины в облаке (AWS, GCP и др.) и запускать на них Docker-контейнеры для обработки пиковых нагрузок.
    *   **Kubernetes**: Запускает каждое задание как Pod внутри кластера Kubernetes, обеспечивая максимальную масштабируемость и отказоустойчивость.
    *   **VirtualBox, Parallels**: Для запуска полноценных виртуальных машин.

1. Этапы выполнения задания:

    *   **Подготовка (Prepare)**: Создается рабочее окружение в зависимости от исполнителя (например, pull Docker-образа).
    *   **Предварительная настройка (Pre-job)**: Runner клонирует репозиторий проекта, восстанавливает кэш (cache), загружает артефакты (artifacts) из предыдущих этапов.
    *   **Выполнение (Run)**: Последовательно выполняются команды, указанные в секциях `script` задания `.gitlab-ci.yml`.
    *   **Последующая обработка (Post-job)**: Сохраняются артефакты, обновляется кэш, выполняется очистка окружения.
    *   **Отправка результата**: Runner отправляет лог выполнения и метаданные (статус, время) обратно на сервер GitLab.

Типы Runner и процесс регистрации

Runner бывают двух уровней:

• Shared Runner: Зарегистрирован на уровне всего инстанса GitLab и доступен для всех проектов (обычно администрируется сисадминами).
• Group/Project Runner: Зарегистрирован для конкретной группы или проекта, что позволяет настроить специализированное окружение (например, с особыми секретами или аппаратными требованиями).

Регистрация — это процесс привязки экземпляра Runner к серверу GitLab. Для этого необходим registration token (токен регистрации), который можно получить в настройках проекта, группы или всего сервера. В процессе регистрации указываются ключевые параметры: URL GitLab, тэги, исполнитель и его опции.

Пример команды регистрации (в интерактивном режиме):

sudo gitlab-runner register

После этого Runner начнет опрашивать сервер на наличие заданий.

Конфигурация и пример

Основные настройки Runner хранятся в файле config.toml. Вот пример конфигурации для Docker-исполнителя:

concurrent = 4 # Максимальное количество заданий, выполняемых параллельно

[[runners]]
  name = "My Docker Runner"
  url = "https://gitlab.example.com"
  token = "PROJECT_REGISTRATION_TOKEN"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_cache = false
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]
    shm_size = 0
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

Когда в проекте срабатывает конвейер, GitLab CI/CD ищет доступный Runner, который соответствует тэгам задания и типу исполнителя. Например, задание с тэгом docker будет выполнено только на Runner, зарегистрированном с этим тэгом.

Ключевые преимущества и сценарии использования

• Масштабируемость: Можно зарегистрировать неограниченное количество Runner на разных машинах (локальных, в облаке, в Kubernetes).
• Гибкость: Разные проекты могут использовать разные исполнители. Можно иметь Runner для сборки на Windows, тестирования на macOS и деплоя в Kubernetes.
• Изоляция и безопасность: Использование Docker или Kubernetes обеспечивает изоляцию заданий друг от друга и от хостовой системы.
• Автомасштабирование: С помощью Docker Machine или Kubernetes можно автоматически добавлять вычислительные мощности в момент высокой нагрузки на конвейеры и удалять их в простое, что оптимизирует затраты.

Таким образом, GitLab Runner выступает в роли распределенного "рабочего", который берет задачи из централизованной очереди GitLab CI/CD, выполняет их в настроенном окружении и обеспечивает обратную связь, являясь техническим фундаментом для автоматизации процессов сборки, тестирования и развертывания.