doc-locale/fr-fr/ci/runners/runners_scope.md
{{< details >}}
{{< /details >}}
GitLab Runner propose les types de runners suivants, disponibles selon les personnes auxquelles vous souhaitez accorder l'accès :
Les runners d'instance sont disponibles pour chaque projet d'une instance GitLab.
Utilisez des runners d'instance lorsque vous avez plusieurs jobs avec des exigences similaires. Plutôt que d'avoir plusieurs runners inactifs pour de nombreux projets, vous pouvez avoir quelques runners qui gèrent plusieurs projets.
Si vous utilisez GitLab Self-Managed, les administrateurs peuvent :
Si vous utilisez GitLab.com :
{{< history >}}
create_runner_workflow_for_admin flagcreate_runner_workflow_for_admin a été supprimé.{{< /history >}}
Prérequis :
Lorsque vous créez un runner, un token d'authentification de runner lui est attribué, que vous utilisez pour l'enregistrer. Le runner utilise le token pour s'authentifier auprès de GitLab lors de la récupération des jobs dans la file d'attente des jobs.
Pour créer un runner d'instance :
GitLab instance URL, utilisez l'URL de votre instance GitLab. Par exemple, si votre projet est hébergé sur gitlab.example.com/yourname/yourproject, l'URL de votre instance GitLab est https://gitlab.example.com.executor, entrez le type d'exécuteur. L'exécuteur est l'environnement dans lequel le runner exécute le job.Vous pouvez également utiliser l'API pour créer un runner.
[!note] Le token d'authentification du runner s'affiche dans l'interface utilisateur pendant une durée limitée lors de l'enregistrement. Après avoir enregistré le runner, le token d'authentification est stocké dans le fichier
config.toml.
[!warning] L'option de transmission des tokens d'enregistrement de runner et la prise en charge de certains arguments de configuration sont considérées comme héritées et ne sont pas recommandées. Utilisez le workflow de création de runner pour générer un token d'authentification afin d'enregistrer des runners. Ce processus assure une traçabilité complète de la propriété des runners et renforce la sécurité de votre flotte de runners. Pour plus d'informations, consultez Migration vers le nouveau workflow d'enregistrement de runner.
Prérequis :
Pour créer un runner d'instance :
Prérequis :
Vous pouvez mettre en pause un runner afin qu'il n'accepte pas les jobs des groupes et des projets de l'instance GitLab.
Prérequis :
Lorsque vous supprimez un runner d'instance, il est définitivement supprimé de l'instance GitLab et ne peut plus être utilisé par les groupes et les projets. Si vous souhaitez arrêter temporairement le runner d'accepter des jobs, vous pouvez à la place le mettre en pause.
Pour supprimer un ou plusieurs runners d'instance :
Sur GitLab.com, les runners d'instance sont activés dans tous les projets par défaut.
Sur GitLab Self-Managed, un administrateur peut les activer pour tous les nouveaux projets.
Pour les projets existants, un administrateur doit les installer et les enregistrer.
Pour activer les runners d'instance pour un projet :
Pour activer les runners d'instance pour un groupe :
Vous pouvez désactiver les runners d'instance pour des projets individuels ou pour des groupes. Vous devez disposer du rôle Propriétaire pour le projet ou le groupe.
Pour désactiver les runners d'instance pour un projet :
Les runners d'instance sont automatiquement désactivés pour un projet :
Pour désactiver les runners d'instance pour un groupe :
Les runners d'instance traitent les jobs en utilisant une file d'attente à usage équitable. Cette file d'attente empêche les projets de créer des centaines de jobs et d'utiliser toutes les ressources disponibles des runners d'instance.
L'algorithme de file d'attente à usage équitable attribue les jobs en fonction des projets qui ont le moins de jobs déjà en cours d'exécution sur les runners d'instance.
Par exemple, si ces jobs sont dans la file d'attente :
Lorsque plusieurs jobs CI/CD s'exécutent simultanément, l'algorithme à usage équitable attribue les jobs dans cet ordre :
Lorsqu'un seul job s'exécute à la fois, l'algorithme à usage équitable attribue les jobs dans cet ordre :
Utilisez des runners de groupe lorsque vous souhaitez que tous les projets d'un groupe aient accès à une flotte de runners.
Les runners de groupe traitent les jobs en utilisant une file d'attente de type premier entré, premier sorti.
{{< history >}}
create_runner_workflow_for_namespace flag. Désactivé par défaut.create_runner_workflow_for_admin a été supprimé.{{< /history >}}
Prérequis :
Vous pouvez créer un runner de groupe pour GitLab Self-Managed ou pour GitLab.com. Lorsque vous créez un runner, un token d'authentification de runner lui est attribué, que vous utilisez pour l'enregistrer. Le runner utilise le token pour s'authentifier auprès de GitLab lorsqu'il récupère des jobs dans la file d'attente des jobs.
Pour créer un runner de groupe :
GitLab instance URL, utilisez l'URL de votre instance GitLab. Par exemple, si votre projet est hébergé sur gitlab.example.com/yourname/yourproject, l'URL de votre instance GitLab est https://gitlab.example.com.executor, entrez le type d'exécuteur. L'exécuteur est l'environnement dans lequel le runner exécute le job.Vous pouvez également utiliser l'API pour créer un runner.
[!note] Le token d'authentification du runner s'affiche dans l'interface utilisateur pendant une courte période seulement lors de l'enregistrement.
{{< history >}}
{{< /history >}}
[!warning] L'option de transmission des tokens d'enregistrement de runner et la prise en charge de certains arguments de configuration sont considérées comme héritées et ne sont pas recommandées. Utilisez le workflow de création de runner pour générer un token d'authentification afin d'enregistrer des runners. Ce processus assure une traçabilité complète de la propriété des runners et renforce la sécurité de votre flotte de runners. Pour plus d'informations, consultez Migration vers le nouveau workflow d'enregistrement de runner.
Prérequis :
Pour créer un runner de groupe :
Vous pouvez également copier le token d'enregistrement et suivre la documentation sur la façon d'enregistrer un runner.
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez afficher tous les runners d'un groupe, de ses sous-groupes et de ses projets. Vous pouvez effectuer cette opération pour GitLab Self-Managed ou pour GitLab.com.
{{< history >}}
runners_finder_all_available a été supprimé.{{< /history >}}
Vous pouvez choisir d'afficher tous les runners dans la liste, ou d'afficher uniquement ceux qui sont hérités de l'instance ou d'autres groupes.
Par défaut, seuls les runners hérités sont affichés.
Pour afficher tous les runners disponibles dans l'instance, y compris les runners d'instance et ceux des autres groupes :
Prérequis :
Vous pouvez mettre en pause un runner afin qu'il n'accepte pas les jobs des sous-groupes et des projets de l'instance GitLab. Si vous mettez en pause un runner de groupe utilisé par plusieurs projets, le runner est mis en pause pour tous les projets.
{{< history >}}
{{< /history >}}
Prérequis :
Lorsque vous supprimez un runner de groupe, il est définitivement supprimé de l'instance GitLab et ne peut plus être utilisé par les sous-groupes et les projets. Si vous souhaitez arrêter temporairement le runner d'accepter des jobs, vous pouvez à la place le mettre en pause.
Pour supprimer un ou plusieurs runners de groupe :
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez nettoyer les runners de groupe qui ont été inactifs pendant plus de sept jours.
Les runners de groupe sont ceux qui ont été créés dans un groupe spécifique.
Vous pouvez consulter les journaux Sidekiq pour voir le résultat du nettoyage. Dans Kibana, vous pouvez utiliser la requête suivante :
{
"query": {
"match_phrase": {
"json.class.keyword": "Ci::Runners::StaleGroupRunnersPruneCronWorker"
}
}
}
Filtrez les entrées où les runners périmés ont été supprimés :
{
"query": {
"range": {
"json.extra.ci_runners_stale_group_runners_prune_cron_worker.total_pruned": {
"gte": 1,
"lt": null
}
}
}
}
Utilisez des runners de projet lorsque vous souhaitez utiliser des runners pour des projets spécifiques. Par exemple, lorsque vous avez :
Vous pouvez configurer un runner de projet pour qu'il soit utilisé par plusieurs projets. Les runners de projet doivent être activés explicitement pour chaque projet.
Les runners de projet traitent les jobs en utilisant une file d'attente de type premier entré, premier sorti (FIFO).
[!note] Les runners de projet ne sont pas automatiquement associés aux projets dupliqués. Une duplication copie bien les paramètres CI/CD du dépôt cloné.
Lorsqu'un runner se connecte pour la première fois à un projet, ce projet devient le propriétaire du runner.
Si vous supprimez le projet propriétaire :
Vous ne pouvez pas désassigner un runner du projet propriétaire. Supprimez plutôt le runner.
{{< history >}}
create_runner_workflow_for_namespace flag. Désactivé par défaut.create_runner_workflow_for_admin a été supprimé.{{< /history >}}
Prérequis :
Vous pouvez créer un runner de projet pour GitLab Self-Managed ou pour GitLab.com. Lorsque vous créez un runner, un token d'authentification de runner lui est attribué, que vous utilisez pour vous enregistrer auprès du runner. Le runner utilise le token pour s'authentifier auprès de GitLab lorsqu'il récupère des jobs dans la file d'attente des jobs.
Pour créer un runner de projet :
GitLab instance URL, utilisez l'URL de votre instance GitLab. Par exemple, si votre projet est hébergé sur gitlab.example.com/yourname/yourproject, l'URL de votre instance GitLab est https://gitlab.example.com.executor, entrez le type d'exécuteur. L'exécuteur est l'environnement dans lequel le runner exécute le job.Vous pouvez également utiliser l'API pour créer un runner.
[!note] Le token d'authentification du runner s'affiche dans l'interface utilisateur pendant une courte période seulement lors de l'enregistrement.
[!warning] L'option de transmission des tokens d'enregistrement de runner et la prise en charge de certains arguments de configuration sont considérées comme héritées et ne sont pas recommandées. Utilisez le workflow de création de runner pour générer un token d'authentification afin d'enregistrer des runners. Ce processus assure une traçabilité complète de la propriété des runners et renforce la sécurité de votre flotte de runners. Pour plus d'informations, consultez Migration vers le nouveau workflow d'enregistrement de runner.
Prérequis :
Pour créer un runner de projet :
Le runner est maintenant activé pour le projet.
Prérequis :
Vous pouvez mettre en pause un runner de projet afin qu'il n'accepte pas les jobs des projets auxquels il est assigné dans l'instance GitLab.
Prérequis :
Lorsque vous supprimez un runner de projet, il est définitivement supprimé de l'instance GitLab et ne peut plus être utilisé par les projets. Si vous souhaitez arrêter temporairement le runner d'accepter des jobs, vous pouvez à la place le mettre en pause.
Lorsque vous supprimez un runner, sa configuration existe toujours dans le fichier config.toml de l'hôte du runner. Si la configuration du runner supprimé est toujours présente dans ce fichier, l'hôte du runner continue de contacter GitLab. Pour éviter un trafic API inutile, vous devez également désinscrire le runner supprimé.
Une fois un runner de projet créé, vous pouvez l'activer pour d'autres projets.
Prérequis : Vous devez disposer du rôle Responsable ou Propriétaire pour :
Pour activer un runner de projet pour un projet :
Vous pouvez modifier un runner de projet depuis n'importe lequel des projets pour lesquels il est activé. Les modifications, qui incluent le déverrouillage et la modification des étiquettes et de la description, affectent tous les projets qui utilisent le runner.
Un administrateur peut activer le runner pour plusieurs projets.
Vous pouvez configurer un runner de projet afin qu'il soit « verrouillé » et ne puisse pas être activé pour d'autres projets. Ce paramètre peut être activé lors du premier enregistrement d'un runner, mais peut également être modifié ultérieurement.
Pour verrouiller ou déverrouiller un runner de projet :
Un runner peut avoir l'un des statuts suivants.
| Statut | Description |
|---|---|
online | Le runner a contacté GitLab au cours des 2 dernières heures et est disponible pour exécuter des jobs. |
offline | Le runner n'a pas contacté GitLab depuis plus de 2 heures et n'est pas disponible pour exécuter des jobs. Vérifiez le runner pour voir si vous pouvez le remettre en ligne. |
stale | Le runner n'a pas contacté GitLab depuis plus de 7 jours. Si le runner a été créé il y a plus de 7 jours, mais n'a jamais contacté l'instance, il est également considéré comme stale. |
never_contacted | Le runner n'a jamais contacté GitLab. Pour que le runner contacte GitLab, exécutez gitlab-runner run. |
GitLab supprime régulièrement les gestionnaires de runners périmés pour maintenir une base de données légère. Si un runner contacte l'instance GitLab, la connexion est recréée.
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
En tant qu'administrateur, vous pouvez consulter les statistiques des runners pour en savoir plus sur les performances de votre flotte de runners.
La valeur Median job queued time est calculée en échantillonnant la durée d'attente dans la file des 100 jobs les plus récents exécutés par les runners d'instance. Seuls les jobs des 5 000 runners les plus récents sont pris en compte.
La médiane est une valeur qui correspond au 50e percentile. La moitié des jobs attendent plus longtemps que la valeur médiane, et l'autre moitié attend moins longtemps que la valeur médiane.
Pour afficher les statistiques des runners :
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Prérequis :
La version de GitLab Runner utilisée par vos runners doit être maintenue à jour.
Pour déterminer quels runners doivent être mis à niveau :
Affichez la liste des runners :
Au-dessus de la liste des runners, consultez le statut :
PATCH, ce qui peut le rendre vulnérable à des failles de sécurité ou à des bugs de haute gravité. Ou bien, le runner est en retard d'une ou plusieurs versions MAJOR par rapport à votre instance GitLab, de sorte que certaines fonctionnalités peuvent ne pas être disponibles ou ne pas fonctionner correctement.Filtrez la liste par statut pour voir quels runners individuels doivent être mis à niveau.
Pour résoudre les problèmes liés aux runners, vous devrez peut-être connaître l'adresse IP du runner. GitLab stocke et affiche l'adresse IP en consultant la source des requêtes HTTP lorsque le runner interroge pour obtenir des jobs. GitLab met automatiquement à jour l'adresse IP du runner chaque fois qu'elle est mise à jour.
L'adresse IP des runners d'instance et des runners de projet peut être trouvée à différents endroits.
Prérequis :
Pour déterminer l'adresse IP d'un runner d'instance :
Pour trouver l'adresse IP d'un runner pour un projet, vous devez disposer du rôle Propriétaire pour le projet.
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Vous pouvez ajouter une note de maintenance pour documenter le runner. Les utilisateurs pouvant modifier le runner voient la note lorsqu'ils consultent les détails du runner.
Utilisez cette fonctionnalité pour informer les autres des conséquences ou des problèmes liés à la modification de la configuration du runner.
{{< history >}}
{{< /history >}}
[!warning] L'option de transmission des tokens d'enregistrement de runner et la prise en charge de certains arguments de configuration sont considérées comme héritées et ne sont pas recommandées. Utilisez le workflow de création de runner pour générer un token d'authentification afin d'enregistrer des runners. Ce processus assure une traçabilité complète de la propriété des runners et renforce la sécurité de votre flotte de runners. Pour plus d'informations, consultez Migration vers le nouveau workflow d'enregistrement de runner.
Dans GitLab 17.0, l'utilisation des tokens d'enregistrement de runner est désactivée dans toutes les instances GitLab.
Prérequis :
Pour activer l'utilisation du token d'enregistrement de runner dans les projets et les groupes :