Как управлять параллелизмом GitLab Runner для параллельных заданий CI

Конвейеры GitLab Continuous Integration (CI) — популярный способ автоматизации сборки, тестирования и выпуска каждый раз, когда вы отправляете код в свой репозиторий. Конвейеры работают одновременно и состоят из последовательных этапов; каждый этап может включать несколько заданий, которые выполняются параллельно во время этапа. Максимальный параллелизм как параллельных заданий, так и конвейеров между экземплярами зависит от конфигурации вашего сервера.

Задания выполняются экземплярами GitLab Runner. Бегуны работают как изолированные процессы, получающие новые задания от управляющего ими сервера GitLab. Когда задание выдается, бегун создаст подпроцесс, который выполняет скрипт CI. Есть несколько переменных, которые определяют, когда бегун примет задание и начнет его выполнять. В этом руководстве мы рассмотрим способы настройки параллельных заданий и конвейеров.

Увеличение количества бегунов

Один из способов разрешить одновременное выполнение большего количества заданий — просто зарегистрировать больше исполнителей. Каждая установка GitLab Runner может регистрировать несколько отдельных экземпляров runner. Они работают независимо друг от друга, и им не обязательно обращаться к одному координирующему серверу.

Используйте команду gitlab-runner register, чтобы добавить новый бегун:

sudo gitlab-runner register

Вам будет предложено предоставить регистрационную информацию с вашего сервера GitLab. Вы можете найти это на странице «Настройки» > «CI/CD» проекта или группы GitLab или перейти в «Обзор» > «Раннеры» в центре администрирования для запуска на уровне экземпляра. Бегуны будут выполнять только задания, исходящие из той области, в которой они зарегистрированы.

Каждый зарегистрированный бегун получает свой раздел в вашем файле /etc/gitlab-runner/config.toml:

# Runner 1
[[runners]]
    executor = "shell"
    ...

# Runner 2
[[runners]]
    executor = "shell"
    ...

# Runner 3
[[runners]]
    executor = "shell"
    ...

Если бы все три исполнителя были зарегистрированы на одном сервере, вы бы увидели до трех заданий, выполняющихся параллельно.

Повышение лимита параллелизма

Вы можете установить разрешенный параллелизм для регистрации конкретного исполнителя, используя поле limit в его блоке конфигурации:

# Runner 1
[[runners]]
    executor = "shell"
    limit = 4

Это изменение позволяет первому исполнителю выполнять до четырех одновременных заданий в подпроцессах. Регистрация другого исполнителя с limit=2 повысит уровень параллелизма до шести заданий, если предположить, что оба исполнителя ссылаются на один и тот же управляющий сервер GitLab.

Обработка «параллельного запроса»

Количество выполняемых активных заданий — не единственная переменная, влияющая на параллелизм. GitLab Runner управляет количеством запросов заданий, которые он может принять, с помощью отдельной переменной request_concurrency.

Это значение определяет количество запросов в очереди, которые бегун будет получать от GitLab. Когда серверу необходимо запланировать новое задание CI, исполнители должны указать, достаточно ли у них ресурсов для его получения. Исполнитель не примет задание, если в очереди уже находится больше запросов, чем позволяет request_concurrency.

Рассмотрим этот пример:

# Runner 1
[[runners]]
    executor = "shell"
    limit = 2
    request_concurrency = 4

Этот бегун будет принимать до четырех одновременных запросов на работу и выполнять до двух одновременно. Дополнительные задания не будут выполняться, пока первые два не будут выполнены.

Уровень глобального параллелизма

GitLab Runner также поддерживает глобальный коэффициент параллелизма, который накладывает общий предел на значения limit, предоставляемые отдельными регистрациями. Вы можете управлять этим значением с помощью параметра concurrency в верхней части файла config.toml:

concurrency = 4

# Runner 1
[[runners]]
    executor = "shell"
    limit = 4

# Runner 2
[[runners]]
    executor = "shell"
    limit = 2

Здесь конфигурация двух бегунов предполагает, что общий параллелизм работы равен шести. Однако наличие глобального параметра concurrency означает, что одновременно будет выполняться не более четырех заданий. Это значение ограничивает общее количество подпроцессов, которые могут быть созданы всей установкой GitLab Runner.

Применение изменений

После внесения необходимых изменений вы можете сохранить свой config.toml и вернуться к работе с конвейерами. Изменения в файле автоматически обнаруживаются GitLab Runner и должны применяться почти сразу.

Вы можете попробовать перезапустить процесс GitLab Runner, если кажется, что новый уровень параллелизма не применяется:

sudo gitlab-runner restart

Это останавливает и запускает службу GitLab Runner, перезагружая файл конфигурации.

Организация конвейеров для параллельных заданий

Если ваши задания в одном конвейере не распараллеливаются, стоит проверить основы вашей конфигурации .gitlab-ci.yml. По умолчанию одновременно выполняются только задания, а не этапы конвейера:

stages:
  test:
  build:
  deploy:

test:
  stage: test
  # ...

build_ios:
  stage: build
  # ...

build_android:
  stage: build
  # ...

deploy_ios:
  stage: deploy
  # ...

deploy_android:
  stage: deploy
  # ...

stages:
  test:
  build:
  deploy:

test:
  stage: test
  # ...

build_ios:
  stage: build
  # ...

build_android:
  stage: build
  # ...

deploy_ios:
  stage: deploy
  needs: ["test", "build_ios"]
  # ...

deploy_android:
  stage: deploy
  needs: ["test", "build_android"]
  # ...