web-dev-qa-db-fra.com

Comment fonctionne la concurrence d'accès gitlab runner?

Q1: Quelle est la différence entre

concurrent = 3

[[runners]]
  ..
  executor = "Shell"

et

concurrent = 3

[[runners]]
  ...
  executor = "Shell"

[[runners]]
  ...
  executor = "Shell"

[[runners]]
  ...
  executor = "Shell"

Q2: Est-il sensé de ...

avoir 3 exécuteurs (workers) de même type sur un seul coureur avec global concurrent = 3? Ou peut un exécuteur unique avec global concurrent = 3 effectuer plusieurs travaux en parallèle en toute sécurité?

Q3: Comment ils sont liés ...

runners.limit avec runners.request_concurrency et concurrent

Merci

gitlabgitlab-cigitlab-ci-runner
8
Slimer

La documentation de Gitlab sur les coureurs les décrit comme:

(...) des machines (virtuelles) isolées qui récupèrent des tâches via l'API coordinatrice de GitLab CI

Par conséquent, chaque coureur est un processus isolé chargé de recueillir les demandes d'exécution de travaux et de les traiter selon des configurations prédéfinies. En tant que processus isolé, chaque coureur a la capacité de créer des "sous-processus" (également appelés machines) afin d'exécuter des travaux.

Lorsque vous définissez dans votre config.toml une [[runner]] section , vous configurez un coureur et définissez comment il doit traiter les demandes d'exécution des travaux. Dans vos questions, vous avez mentionné deux de ces paramètres "comment traiter la demande d'exécution de travail":

  1. limit: "Limitez le nombre de travaux pouvant être traités simultanément". En d'autres termes, combien de "sous-processus" peuvent être créés par un coureur afin d'exécuter des tâches simultanément;
  2. request_concurrency: "Limiter le nombre de demandes simultanées de nouveaux travaux de GitLab". En d'autres termes, combien de demandes d'exécution de travail un runner peut-il prendre simultanément dans la file d'attente de travaux GitLab CI.

En outre, il existe certains paramètres qui s'appliquent à une machine dans le monde . Dans votre question, vous en avez mentionné un:

  1. concurrent: "Limitez le nombre de travaux globalement pouvant être exécutés simultanément. Il s'agit de la limite la plus élevée du nombre de travaux utilisant tous les coureurs définis". En d'autres termes, il limite la quantité maximale de "sous-processus" pouvant exécuter simultanément des travaux.

Ainsi, en gardant à l'esprit la différence entre un coureur et ses sous-processus ainsi que la différence entre les paramètres spécifiques du coureur et les paramètres globaux de la machine:

Q1:

La différence est que dans votre 1er exemple, vous avez un coureur et dans votre 2ème exemple vous avez trois coureurs . Il convient de mentionner que dans les deux exemples, votre machine ne permet d'exécuter que 3 tâches simultanément.

Q2:

Non seulement un seul exécuteur peut exécuter plusieurs travaux simultanément en toute sécurité, mais il est également possible de contrôler le nombre de travaux que vous souhaitez qu'il gère (en utilisant le paramètre limit susmentionné).

De plus, il n'y a aucun problème à avoir des coureurs similaires exécutés sur la même machine. La façon dont vous allez définir les configurations de votre coureur dépend de vous et des capacités de votre infrastructure.

Notez également que an executor définit uniquement comment exécuter votre travail. Ce n'est pas la seule chose qui définit un coureur et ce n'est pas non plus synonyme de "travailleur". Ceux qui travaillent sont vos coureurs et leurs sous-processus.

Q3:

Pour résumer: Vous pouvez définir un ou plusieurs travailleurs sur la même machine. Chacun est un processus isolé. limit d'un runner est le nombre de sous-processus d'un processus runner qui peuvent être créés pour exécuter des travaux simultanément. Un coureur request_concurrency est le nombre de requêtes qu'un coureur peut gérer à partir de la file d'attente de travaux Gitlab CI. Enfin, la définition d'une valeur sur concurrent limitera le nombre de travaux pouvant être exécutés sur votre machine en même temps dans le ou les coureurs exécutés sur la machine.

Références

Pour une meilleure compréhension, je vous recommande vraiment de lire algorithme et paramètres de mise à l'échelle automatique .

Enfin, je pense que vous pourriez trouver cette question sur la façon de exécuter des coureurs en parallèle sur le même serveur utile.

13
Aurora Wang