Comment gérer la simultanéité de GitLab Runner pour les tâches CI parallèles – CloudSavvy IT
Les pipelines d’intégration continue (CI) de GitLab sont un moyen populaire d’automatiser les builds, les tests et les versions chaque fois que vous poussez du code vers votre référentiel. Les pipelines fonctionnent simultanément et se composent d’étapes séquentielles ; chaque étape peut inclure plusieurs tâches qui s’exécutent en parallèle pendant l’étape. La simultanéité maximale des travaux parallèles et des pipelines entre instances dépend de la configuration de votre serveur.
Les tâches sont exécutées par des instances GitLab Runner. Les exécuteurs fonctionnent comme des processus isolés qui reçoivent de nouvelles tâches de leur serveur GitLab de contrôle. Lorsqu’un travail est émis, l’exécuteur crée un sous-processus qui exécute le script CI. Il existe plusieurs variables qui contrôlent le moment où un exécuteur acceptera une tâche et commencera à l’exécuter. Dans ce guide, nous examinerons les façons dont vous pouvez configurer des travaux et des pipelines parallèles.
Sommaire
Augmenter le nombre de coureurs
Une façon de permettre à plus de tâches de s’exécuter simultanément consiste à enregistrer simplement plus de coureurs. Chaque installation de GitLab Runner peut enregistrer plusieurs instances d’exécution distinctes. Ils fonctionnent indépendamment les uns des autres et n’ont pas tous besoin de se référer au même serveur de coordination.
Utilisez le gitlab-runner register commande pour ajouter un nouveau coureur :
sudo gitlab-runner register
Vous serez invité à fournir les informations d’enregistrement à partir de votre serveur GitLab. Vous pouvez le trouver sur la page Paramètres > CI/CD d’un projet ou d’un groupe GitLab, ou accédez à Présentation > Exécuteurs dans le centre d’administration pour un exécuteur au niveau de l’instance. Les exécuteurs n’exécuteront que les tâches provenant de la portée dans laquelle ils sont enregistrés.
Chaque coureur inscrit a sa propre section dans votre /etc/gitlab-runner/config.toml fichier:
# Runner 1
[[runners]]
executor = "shell"
...
# Runner 2
[[runners]]
executor = "shell"
...
# Runner 3
[[runners]]
executor = "shell"
...
Si les trois programmes d’exécution étaient enregistrés sur le même serveur, vous verriez désormais jusqu’à trois tâches s’exécuter en parallèle.
Augmentation de la limite de simultanéité
Vous pouvez définir la simultanéité autorisée d’une inscription de coureur spécifique à l’aide du limit champ dans son bloc de configuration :
# Runner 1
[[runners]]
executor = "shell"
limit = 4
Cette modification permet au premier programme d’exécution d’exécuter jusqu’à quatre tâches simultanées dans des sous-processus. Inscrire un autre coureur avec limit = 2 augmenterait le niveau de simultanéité à un total de six tâches, en supposant que les deux exécuteurs référençaient le même serveur GitLab de contrôle.
Gestion de la « demande de simultanéité »
Le nombre de travaux en cours d’exécution n’est pas la seule variable qui a un impact sur la simultanéité. GitLab Runner gère le nombre de demandes d’emploi il peut accepter via le request_concurrency variable.
Cette valeur contrôle le nombre de requêtes en file d’attente que l’exécuteur prendra à partir de GitLab. Lorsque le serveur doit planifier une nouvelle tâche CI, les exécuteurs doivent indiquer s’ils ont une capacité suffisante pour la recevoir. L’exécuteur n’acceptera pas le travail s’il contient déjà plus de requêtes en file d’attente que request_concurrency permis.
Considérez cet exemple :
# Runner 1
[[runners]]
executor = "shell"
limit = 2
request_concurrency = 4
Ce programme d’exécution acceptera jusqu’à quatre demandes de travail simultanées et en exécutera jusqu’à deux simultanément. Les travaux supplémentaires ne seront pas pris avant que les deux premiers ne soient terminés.
Le niveau global de simultanéité
GitLab Runner maintient également un facteur de simultanéité global qui place un plafond global sur le limit valeurs exposées par les enregistrements individuels. Vous pouvez contrôler cette valeur avec le concurrency réglage au sommet de votre config.toml:
concurrency = 4
# Runner 1
[[runners]]
executor = "shell"
limit = 4
# Runner 2
[[runners]]
executor = "shell"
limit = 2
Ici, la configuration des deux exécuteurs suggère une simultanéité totale des tâches de six. Cependant, la présence du monde concurrency paramètre signifie que pas plus de quatre tâches seront réellement exécutées simultanément. Cette valeur limite le nombre total de sous-processus pouvant être créés par l’ensemble de l’installation de GitLab Runner.
Application des modifications
Une fois que vous avez apporté les modifications nécessaires, vous pouvez enregistrer votre config.toml et reprenez l’exécution de vos pipelines. Les modifications apportées au fichier sont automatiquement détectées par GitLab Runner et devraient s’appliquer presque immédiatement.
Vous pouvez essayer de redémarrer le processus GitLab Runner si le nouveau niveau de simultanéité ne semble pas s’être appliqué :
sudo gitlab-runner restart
Cela arrête et démarre le service GitLab Runner, rechargeant le fichier de configuration.
Organisation de vos pipelines pour des tâches parallèles
Si vos travaux dans un pipeline unique ne sont pas parallélisés, il est utile de vérifier les bases de votre .gitlab-ci.yml configuration. C’est seulement travaux qui s’exécutent simultanément par défaut, pas les étapes du pipeline :
stages: test: build: deploy: test: stage: test # ... build_ios: stage: build # ... build_android: stage: build # ... deploy_ios: stage: deploy # ... deploy_android: stage: deploy # ...
Ce pipeline définit trois étapes qui sont affichées horizontalement dans l’interface utilisateur GitLab. Chaque étape doit être terminée avant que la suivante puisse commencer. le build et deploy les étapes ont deux emplois chacune. Ces tâches s’exécutent en parallèle si vos programmes d’exécution disposent d’une capacité suffisante pour respecter leurs limites de simultanéité configurées.
Il est possible d’enfreindre la règle « les étapes s’exécutent séquentiellement » en utilisant le needs mot-clé pour construire un graphe acyclique dirigé :
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"] # ...
Ici, le déploiement iOS est autorisé à se poursuivre dès que le build_ios travail est terminé, même si le reste du build l’étape n’est pas terminée. En utilisant needs rend vos pipelines plus flexibles en ajoutant de nouvelles opportunités de parallélisation. Cependant, cela entraîne également une complexité qui peut être plus difficile à maintenir au fil du temps à mesure que vous ajoutez plus de travaux à votre pipeline.
Qu’en est-il de la mise en cache ?
L’utilisation de la simultanéité signifie que vos tâches peuvent être récupérées par différents exécuteurs à chaque passage dans un pipeline particulier. Les exécuteurs maintiennent leurs propres instances de cache, de sorte qu’il n’est pas garanti qu’un travail atteigne un cache même si une exécution précédente dans le pipeline en a rempli une. Le cache peut résider sur un exécuteur différent de celui qui exécute le deuxième travail.
Vous pouvez résoudre ce problème en configurant un fournisseur de cache partagé à l’aide d’un système de stockage d’objets compatible S3. Cela entraînera le téléchargement des caches vers ce fournisseur une fois le travail terminé, stockant le contenu indépendamment de tout exécuteur spécifique. D’autres instances d’exécution pourront récupérer le cache du serveur de stockage d’objets même si elles ne l’ont pas créé.
La mise en cache partagée peut améliorer les performances en augmentant la probabilité d’un accès au cache, ce qui réduit le travail que vos tâches doivent accomplir. Vos pipelines ne devraient pas exiger résolution de cache réussie cependant : les caches sont utilisés au mieux, de sorte que les scripts CI sont censés être résistants aux échecs.
Sommaire
GitLab Runner vous offre trois contrôles principaux pour gérer la simultanéité : le limit et request_concurrency champs sur les coureurs individuels, et le concurrency valeur de l’ensemble de l’installation. Une installation particulière de Runner ne s’exécutera pas plus de <concurrency> emplois simultanément, même si la somme de ses inscriptions limit valeurs suggèrent que cela pourrait prendre plus.
L’ajout de coureurs supplémentaires est un autre moyen d’avoir un impact sur la simultanéité globale. En général, il est préférable d’augmenter la simultanéité sur un exécuteur existant si vous souhaitez simplement exécuter plus de tâches avec la même configuration. Ajoutez un nouveau coureur et définissez son limit lorsque vous devez exécuter des tâches avec un nouvel exécuteur ou des paramètres différents de votre flotte existante.
