doc-locale/fr-fr/ci/runners/new_creation_workflow.md
{{< details >}}
{{< /details >}}
[!disclaimer]
GitLab 16.0 a introduit un nouveau workflow de création de runners qui utilise des jetons d'authentification de runner pour enregistrer les runners. Le workflow hérité qui utilise des jetons d'enregistrement n'est pas recommandé. Utilisez plutôt le workflow de création de runners.
Pour obtenir des informations sur le statut de développement actuel du nouveau workflow, consultez l'epic 7663.
Pour obtenir des informations sur la conception technique et les raisons de la nouvelle architecture, consultez next GitLab Runner Token architecture.
Si vous rencontrez des problèmes ou avez des préoccupations concernant le nouveau workflow d'enregistrement des runners, ou si vous avez besoin de plus d'informations, faites-le nous savoir dans le ticket de feedback.
Pour le nouveau workflow d'enregistrement des runners, vous devez :
Le nouveau workflow d'enregistrement des runners présente les avantages suivants :
Dans GitLab 16.11 et les versions antérieures, vous pouvez utiliser le workflow hérité d'enregistrement des runners.
Dans GitLab 17.0 et les versions ultérieures, le workflow hérité d'enregistrement des runners peut être désactivé par les administrateurs d'instance ou les propriétaires de groupe. Pour plus d'informations, consultez Utilisation des jetons d'enregistrement après GitLab 17.0.
Si vous enregistrez un runner sans migrer vers le nouveau workflow, l'enregistrement du runner échoue et la commande gitlab-runner register retourne une erreur 410 Gone - runner registration disallowed.
Pour éviter un workflow dysfonctionnel, vous devez :
Pour continuer à utiliser des jetons d'enregistrement après GitLab 17.0 :
Les runners existants continueront à fonctionner normalement après la mise à niveau vers GitLab 17.0. Cette modification affecte uniquement l'enregistrement des nouveaux runners.
Le chart Helm GitLab Runner génère de nouveaux pods de runner à chaque exécution d'un job. Pour ces runners, activez l'enregistrement hérité des runners pour utiliser les jetons d'enregistrement.
gitlab-runner register {#changes-to-the-gitlab-runner-register-command-syntax}La commande gitlab-runner register accepte des jetons d'authentification de runner à la place des jetons d'enregistrement. Vous pouvez générer des jetons depuis la page Runners dans la zone Admin. Les jetons d'authentification de runner sont reconnaissables par leur préfixe glrt-.
Lorsque vous créez un runner dans l'interface GitLab, vous spécifiez des valeurs de configuration qui étaient auparavant des options de ligne de commande demandées par la commande gitlab-runner register.
Si vous spécifiez un jeton d'authentification de runner avec :
--token, la commande gitlab-runner register n'accepte pas les valeurs de configuration.--registration-token, la commande gitlab-runner register ignore les valeurs de configuration.| Jeton | Commande d'enregistrement |
|---|---|
| Jeton d'authentification de runner | gitlab-runner register --token $RUNNER_AUTHENTICATION_TOKEN |
| Jeton d'enregistrement de runner (hérité) | gitlab-runner register --registration-token $RUNNER_REGISTRATION_TOKEN <runner configuration arguments> |
Les jetons d'authentification ont le préfixe glrt-.
Pour assurer une interruption minimale de votre workflow d'automatisation, le traitement d'enregistrement compatible avec le mode hérité se déclenche si un jeton d'authentification de runner est spécifié dans le paramètre hérité --registration-token.
Exemple de commande pour GitLab 15.9 :
gitlab-runner register \
--non-interactive \
--executor "shell" \
--url "https://gitlab.com/" \
--tag-list "shell,mac,gdk,test" \
--run-untagged "false" \
--locked "false" \
--access-level "not_protected" \
--registration-token "REDACTED"
Dans GitLab 15.10 et les versions ultérieures, vous pouvez créer le runner et définir des attributs dans l'interface, tels que la liste de tags, le statut de verrouillage et le niveau d'accès. Dans GitLab 15.11 et les versions ultérieures, ces attributs ne sont plus acceptés comme arguments de register lorsqu'un jeton d'authentification de runner avec le préfixe glrt- est spécifié.
L'exemple suivant montre la nouvelle commande :
gitlab-runner register \
--non-interactive \
--executor "shell" \
--url "https://gitlab.com/" \
--token "REDACTED"
Dans les scénarios de mise à l'échelle automatique tels que GitLab Runner Operator ou GitLab Runner Helm Chart, le jeton d'authentification de runner généré depuis l'interface remplace le jeton d'enregistrement. Cela signifie que la même configuration de runner est réutilisée pour les jobs, au lieu de créer un runner pour chaque job. Le runner spécifique peut être identifié par l'ID système unique qui est généré au démarrage du processus du runner.
Dans GitLab 15.11 et les versions ultérieures, vous pouvez utiliser l'API REST POST /user/runners pour créer un runner en tant qu'utilisateur authentifié. Cette méthode ne doit être utilisée que si la configuration du runner est dynamique ou non réutilisable. Si la configuration du runner est statique, vous devez réutiliser le jeton d'authentification de runner d'un runner existant.
Pour obtenir des instructions sur la façon d'automatiser la création et l'enregistrement des runners, consultez le tutoriel Automate runner creation and registration.
Plusieurs options de configuration des runners ne peuvent pas être définies lors de l'enregistrement des runners si les jetons d'enregistrement des runners sont désactivés. Ces options ne peuvent être configurées que :
user/runners.Les options de configuration suivantes ne sont pas prises en charge dans values.yaml dans ce scénario :
## If a runner authentication token is specified in runnerRegistrationToken, the registration will succeed, however the
## other values will be ignored.
runnerRegistrationToken: ""
locked: true
tags: ""
maximumTimeout: ""
runUntagged: true
protected: true
Pour GitLab Runner sur Kubernetes, le déploiement Helm transmet le jeton d'authentification de runner au pod worker du runner et crée la configuration du runner. Dans GitLab 17.0 et les versions ultérieures, si vous utilisez le champ de jeton runnerRegistrationToken sur les runners hébergés sur Kubernetes attachés à GitLab.com, le pod worker du runner tente d'utiliser la méthode API d'enregistrement héritée lors de la création.
Remplacez le champ runnerRegistrationToken non valide par le champ runnerToken. Vous devez également modifier le jeton d'authentification de runner stocké dans secrets.
Dans le workflow hérité d'enregistrement des runners, les champs étaient spécifiés avec :
apiVersion: v1
kind: Secret
metadata:
name: gitlab-runner-secret
type: Opaque
data:
runner-registration-token: "REDACTED" # DEPRECATED, set to ""
runner-token: ""
Dans le nouveau workflow d'enregistrement des runners, vous devez utiliser runner-token à la place :
apiVersion: v1
kind: Secret
metadata:
name: gitlab-runner-secret
type: Opaque
data:
runner-registration-token: "" # need to leave as an empty string for compatibility reasons
runner-token: "REDACTED"
[!note] Si votre solution de gestion des secrets ne vous permet pas de définir une chaîne vide pour
runner-registration-token, vous pouvez la définir sur n'importe quelle chaîne. Cette valeur est ignorée lorsquerunner-tokenest présent.
Lorsque vous utilisez le nouveau workflow d'enregistrement pour enregistrer vos runners avec un chart Helm, le nom du pod n'apparaît pas dans la page de détails du runner. Pour plus d'informations, consultez le ticket 423523.
Lorsque vous enregistrez des runners sur plusieurs machines hôtes via le nouveau workflow avec la rotation automatique des jetons, seul le premier gestionnaire de runners reçoit le nouveau jeton. Les gestionnaires de runners restants continuent à utiliser le jeton non valide et se déconnectent. Vous devez mettre à jour ces gestionnaires manuellement pour utiliser le nouveau jeton.
Lors de l'enregistrement des runners avec GitLab Operator via le nouveau workflow, le jeton d'authentification de runner dans la Custom Resource Definition ne se met pas à jour lors de la rotation des jetons. Cela se produit lorsque :
glrt-) dans un secret référencé par une Custom Resource Definition.Pour plus d'informations, consultez le ticket 186.