Как работает параллелизм Gitlab Runner? - PullRequest
Новая
       9

Как работает параллелизм Gitlab Runner?

0 голосов
/ 05 февраля 2019

Q1: В чем разница между 

concurrent = 3

[[runners]]
  ..
  executor = "shell"

и 

concurrent = 3

[[runners]]
  ...
  executor = "shell"

[[runners]]
  ...
  executor = "shell"

[[runners]]
  ...
  executor = "shell"

Q2: Имеет ли смысл, чтобы ...

имели 3 исполнителя (workers) из того же типа на одном бегунке с глобальным concurrent = 3?Или может один исполнитель с глобальным concurrent = 3 безопасно выполнять несколько заданий параллельно?

Q3: Как они связаны ...

runners.limit с runners.request_concurrency и concurrent

Спасибо

1 Ответ

0 голосов
/ 15 марта 2019

Документация Gitlab по бегунам описывает их как:

(...) изолированные (виртуальные) машины, которые получают задания через API-координатор GitLab CI

Таким образом, каждый участник является изолированным процессом, отвечающим за сбор запросов на выполнение заданий и обработку их в соответствии с предопределенными конфигурациями.В качестве изолированного процесса каждый участник может создавать «подпроцессы» (также называемые машинами) для запуска заданий.

Когда вы определяете в своем разделе config.toml a [[runner]], вы настраиваете бегуна и настраиваете, как он должен обрабатывать запросы на выполнение задания.В своих вопросах вы упомянули две из этих настроек «как работать с запросом на выполнение задания»:

  1. limit: «Ограничить количество одновременно выполняемых заданий».Другими словами, сколько «подпроцессов» может быть создано бегуном для одновременного выполнения заданий:
  2. request_concurrency: «Ограничить число одновременных запросов на новые задания от GitLab».Другими словами, сколько запросов на выполнение задания может одновременно принять участник из очереди заданий GitLab CI.

Кроме того, существуют некоторые настройки , которые применяются к компьютеру в целом .В своем вопросе вы упомянули один из них:

  1. concurrent: «Ограничить число одновременных заданий, выполняемых в глобальном масштабе. Это самый верхний предел количества заданий, использующих все определенные исполнители».Другими словами, он ограничивает максимальное количество «подпроцессов», которые могут одновременно выполнять задания.

Таким образом, имея в виду разницу между бегущим и его подпроцессами, а также разницу между конкретныминастройки бегуна и общие настройки машины:

Q1:

Разница в том, что в вашем 1-м примере у вас есть один бегун и в вашем 2-й пример, у вас есть три бегуна .Стоит отметить, что в обоих примерах ваша машина будет позволять запускать только 3 задания одновременно.

Q2:

Не только один бегун может одновременно безопасно выполнять несколько заданий, но также можно контролировать, сколькозаданий, которые вы хотите обрабатывать (используя вышеупомянутую настройку limit).

Кроме того, нет проблем с запуском похожих бегунов на одном и том же компьютере.Как вы будете определять конфигурации вашего бегуна, зависит от вас и от возможностей вашей инфраструктуры.

Также обратите внимание, что и executor определяют только то, как выполнять вашу работу.Это не единственное, что определяет бегуна, и это не синоним слова «работник».Те, кто работают, - это ваши бегуны и их подпроцессы.

Q3:

Подводя итог: вы можете определить одного или нескольких рабочих на одном компьютере.Каждый из них является изолированным процессом.limit для бегуна - это количество подпроцессов процесса бегуна для одновременного запуска заданий.request_concurrency для бегуна - это то, сколько запросов может обработать бегун из очереди заданий Gitlab CI.Наконец, установка значения concurrent ограничит количество одновременно выполняемых заданий на вашем компьютере одним или несколькими бегунами, работающими на нем.

Ссылки

В лучшую сторонупонимая, я действительно рекомендую вам прочитать о Алгоритм автоматического масштабирования и параметры .

Наконец, я думаю, что вам может пригодиться этот вопрос о том, как параллельно запускать бегуны на одном и том же сервере полезно.

...