{"meta":{"title":"Résolution des erreurs d’Actions Runner Controller","intro":"Découvrez comment résoudre les erreurs liées à Actions Runner Controller.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/tutorials","title":"Tutoriels"},{"href":"/fr/actions/tutorials/use-actions-runner-controller","title":"Actions Runner Controller (Contrôleur de Gestionnaire d'Actions)"},{"href":"/fr/actions/tutorials/use-actions-runner-controller/troubleshoot","title":"Dépanner"}],"documentType":"article"},"body":"# Résolution des erreurs d’Actions Runner Controller\n\nDécouvrez comment résoudre les erreurs liées à Actions Runner Controller.\n\n## Journalisation\n\nLes ressources Actions Runner Controller (ARC), qui incluent le contrôleur, l’écouteur et les exécuteurs, écrivent des journaux dans la sortie standard (`stdout`). Nous vous recommandons d’implémenter une solution de journalisation pour collecter et stocker ces journaux. La disponibilité des journaux peut vous aider ou aider le support GitHub à résoudre les problèmes et à effectuer le débogage. Pour plus d’informations, consultez [Architecture de journalisation](https://kubernetes.io/docs/concepts/cluster-administration/logging/) dans la documentation de Kubernetes.\n\n## Étiquettes de ressources\n\nLes étiquettes sont ajoutées aux ressources créées par Actions Runner Controller, qui incluent les pods du contrôleur, de l’écouteur et de l’exécuteur. Vous pouvez utiliser ces étiquettes pour filtrer les ressources et faciliter la résolution des problèmes.\n\n### Pod du contrôleur\n\nLes étiquettes suivantes sont appliquées au pod du contrôleur.\n\n```yaml\napp.kubernetes.io/component=controller-manager\napp.kubernetes.io/instance=<controller installation name>\napp.kubernetes.io/name=gha-runner-scale-set-controller\napp.kubernetes.io/part-of=gha-runner-scale-set-controller\napp.kubernetes.io/version=<chart version>\n```\n\n### Pod de réception\n\nLes étiquettes suivantes sont appliquées au pod de l’écouteur.\n\n```yaml\nactions.github.com/enterprise= # Will be populated if githubConfigUrl is an enterprise URL\nactions.github.com/organization= # Will be populated if githubConfigUrl is an organization URL\nactions.github.com/repository= # Will be populated if githubConfigUrl is a repository URL\nactions.github.com/scale-set-name= # Runners scale set name\nactions.github.com/scale-set-namespace= # Runners namespace\napp.kubernetes.io/component=runner-scale-set-listener\napp.kubernetes.io/part-of=gha-runner-scale-set\napp.kubernetes.io/version= # Chart version\n```\n\n### Pod de l’exécuteur\n\nLes étiquettes suivantes sont appliquées au pod de l’exécuteur.\n\n```yaml\nactions-ephemeral-runner= # True | False\nactions.github.com/organization= # Will be populated if githubConfigUrl is an organization URL\nactions.github.com/scale-set-name= # Runners scale set name\nactions.github.com/scale-set-namespace= # Runners namespace\napp.kubernetes.io/component=runner\napp.kubernetes.io/part-of=gha-runner-scale-set\napp.kubernetes.io/version= # Chart version\n```\n\n## Vérification des journaux du contrôleur et de l’écouteur du jeu d’exécuteurs\n\nPour vérifier les logs du pod du contrôleur, vous pouvez utiliser la commande suivante.\n\n```bash copy\nkubectl logs -n <CONTROLLER_NAMESPACE> -l app.kubernetes.io/name=gha-runner-scale-set-controller\n```\n\nPour vérifier les journaux de l’écouteur du jeu d’exécuteurs, vous pouvez utiliser la commande suivante.\n\n```bash copy\nkubectl logs -n <CONTROLLER_NAMESPACE> -l auto-scaling-runner-set-namespace=arc-systems -l auto-scaling-runner-set-name=arc-runner-set\n```\n\n## Utilisation des graphiques de la branche `master`\n\nNous vous recommandons d’utiliser les graphiques de la dernière version au lieu de ceux de la branche `master`. La branche `master` est hautement instable et nous ne pouvons pas garantir le bon fonctionnement des graphiques de la branche `master`.\n\n## Résolution des problèmes liés au pod de l’écouteur\n\nSi le pod du contrôleur est en cours d’exécution, mais que le pod de l’écouteur ne l’est pas, examinez d’abord les journaux du contrôleur pour voir s’il y a des erreurs. S’il n’y a aucune erreur et que le pod de l’écouteur du jeu d’exécuteurs n’est toujours pas en cours d’exécution, vérifiez que le pod du contrôleur a accès au serveur d’API Kubernetes dans votre cluster.\n\nSi vous avez configuré un proxy ou si vous utilisez un proxy side-car qui est automatiquement injecté, comme [Istio](https://istio.io/), vérifiez qu’il est configuré pour autoriser le trafic à partir du conteneur du contrôleur (gestionnaire) vers le serveur d’API Kubernetes.\n\nSi vous avez installé le jeu d’exécuteurs de mise à l’échelle automatique, mais que le pod de l’écouteur n’est pas créé, vérifiez que le `githubConfigSecret` que vous avez fourni est correct et que la valeur `githubConfigUrl` que vous avez fournie est exacte. Pour plus d’informations, consultez « [Authentification d'ARC pour l'API GitHub](/fr/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/authenticating-to-the-github-api) » et « [Déploiement de groupes identiques d’exécuteurs avec Actions Runner Controller](/fr/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller) ».\n\n## Les pods de l’exécuteur sont recréés après une exécution de flux de travail annulée\n\nUne fois l’exécution d’un flux de travail annulée, les événements suivants se produisent.\n\n* Le signal d’annulation est envoyé directement aux exécuteurs.\n* L’application de l’exécuteur s’arrête, ce qui arrête également les pods de l’exécuteur.\n* Lors du prochain sondage, le signal d’annulation est reçu par l’écouteur.\n\nIl peut y avoir un léger décalage entre le moment où les coureurs reçoivent le signal et le moment où l'écouteur reçoit le signal. Lorsque les pods de l’exécuteur commencent à s’arrêter, l’écouteur tente de connecter d’autres exécuteurs pour respecter le nombre souhaité d’exécuteurs en fonction de l’état dans lequel il se trouve. Toutefois, lorsque l’écouteur reçoit le signal d’annulation, il agit pour réduire le nombre d’exécuteurs. Finalement, l’écouteur effectue un scale-down jusqu’à atteindre le nombre souhaité d’exécuteurs. Dans l’intervalle, des exécuteurs supplémentaires peuvent apparaître.\n\n## Erreur : `Name must have up to n characters`\n\nARC utilise les noms générés de certaines ressources comme étiquettes pour d’autres ressources. En raison de cette exigence, ARC limite les noms de ressources à 63 caractères.\n\nÉtant donné que vous définissez une partie du nom de la ressource, ARC impose une limite au nombre de caractères que vous pouvez utiliser pour le nom et l’espace de noms de l’installation.\n\n```bash\nError: INSTALLATION FAILED: execution error at (gha-runner-scale-set/templates/autoscalingrunnerset.yaml:5:5): Name must have up to 45 characters\n\nError: INSTALLATION FAILED: execution error at (gha-runner-scale-set/templates/autoscalingrunnerset.yaml:8:5): Namespace must have up to 63 characters\n```\n\n## Erreur : `Access to the path /home/runner/_work/_tool is denied`\n\nCette erreur peut s’afficher si vous utilisez le mode Kubernetes avec des volumes persistants. Cette erreur se produit si le conteneur de l’exécuteur fonctionne avec un utilisateur non root, provoquant un conflit d'autorisations avec le volume monté.\n\nPour résoudre ce problème, effectuez l’une des opérations suivantes.\n\n* Utilisez un type de volume qui prend en charge `securityContext.fsGroup`. Les volumes `hostPath` ne prennent pas en charge cette propriété, tandis que les volumes `local` et d’autres types de volumes la prennent en charge. Mettez à jour le `fsGroup` du pod de votre exécuteur pour qu’il corresponde au GID de l’exécuteur. Pour ce faire, mettez à jour les valeurs du graphique Helm `gha-runner-scale-set` pour inclure les éléments suivants. Remplacez `VERSION` par la version de l’image conteneur `actions-runner` que vous souhaitez utiliser.\n\n  ```yaml copy\n  template:\n    spec:\n      securityContext:\n        fsGroup: 123\n      containers:\n        - name: runner\n          image: ghcr.io/actions/actions-runner:latest\n          command: [\"/home/runner/run.sh\"]\n  ```\n\n* Si la mise à jour de `securityContext` du pod de votre exécuteur n’est pas une solution viable, vous pouvez contourner le problème en utilisant `initContainers` pour modifier la propriété du volume monté, comme suit.\n\n  ```yaml copy\n  template:\n    spec:\n      initContainers:\n        - name: kube-init\n          image: ghcr.io/actions/actions-runner:latest\n          command: [\"sudo\", \"chown\", \"-R\", \"1001:123\", \"/home/runner/_work\"]\n      volumeMounts:\n        - name: work\n          mountPath: /home/runner/_work\n      containers:\n        - name: runner\n          image: ghcr.io/actions/actions-runner:latest\n          command: [\"/home/runner/run.sh\"]\n  ```\n\n## Erreur : `failed to get access token for GitHub App auth: 401 Unauthorized`\n\nUne erreur `401 Unauthorized` lors de la tentative d’obtention d’un jeton d’accès pour un GitHub App pourrait être le résultat d’une dérive du protocole NTP (Network Time Protocol). Assurez-vous que votre système Kubernetes se synchronise correctement avec un serveur NTP et qu’aucune dérive temporelle significative ne se produit. La marge de manœuvre est plus grande si l’heure de votre système est en retard par rapport à celle de GitHub, mais si l’environnement est en avance de plus de quelques secondes, des erreurs 401 se produiront lors de l’utilisation de GitHub App.\n\n## Limites du groupe d’exécuteurs\n\nVous pouvez avoir un maximum de 10 000 exécuteurs auto-hébergés dans un groupe d’exécuteurs. Si cette limite est atteinte, l’ajout d’un nouvel exécuteur n’est pas possible.\n\n## Mises à jour du runner\n\n> \\[!WARNING] Toutes les mises à jour publiées pour le logiciel, y compris les versions majeures, mineures ou correctives, sont considérées comme une mise à jour disponible. Si vous n’effectuez pas de mise à jour de logiciel dans les 30 jours, le service GitHub Actions ne met pas en file d’attente les travaux pour votre exécuteur. En outre, si une mise à jour de sécurité critique est requise, le service GitHub Actions ne met pas en file d’attente les travaux pour votre exécuteur tant qu’il n’a pas été mis à jour.\n\nVérifiez que votre version logicielle de l’exécuteur et/ou les images d’exécuteur personnalisées en cours d’utilisation exécutent la dernière version.\n\nPour plus d’informations, consultez « [Documentation de référence relative aux runners auto-hébergés](/fr/actions/reference/runners/self-hosted-runners) ».\n\n## Mentions légales\n\nCertaines parties ont été adaptées à partir de <https://github.com/actions/actions-runner-controller/> sous la licence Apache-2.0 :\n\n```text\nCopyright 2019 Moto Ishizawa\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n    http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n```"}