Mise à l’échelle automatique avec des exécuteurs auto-hébergés

Vous pouvez mettre automatiquement à l’échelle vos exécuteurs autohébergés en réponse aux événements de webhook.

Dans cet article

À propos de la mise à l’échelle automatique

Vous pouvez augmenter ou diminuer automatiquement le nombre d’exécuteurs auto-hébergés dans votre environnement en réponse aux événements de webhook que vous recevez avec une étiquette particulière. Par exemple, vous pouvez créer une automatisation qui ajoute un nouvel exécuteur auto-hébergé chaque fois que vous recevez un événement webhook workflow_job avec l’activité queued, ce qui vous informe qu’un nouveau travail est prêt à être traité. La charge utile de webhook inclut des données d’étiquette, afin que vous puissiez identifier le type d’exécuteur que le travail demande. Une fois le travail terminé, vous pouvez créer une automatisation qui supprime l’exécuteur en réponse à l’activité workflow_job completed.

Solutions de mise à l’échelle automatique prises en charge

GitHubLes exécuteurs hébergés s'adaptent automatiquement à vos besoins. GitHub Les exécuteurs hébergés peuvent constituer une alternative peu coûteuse et nécessitant peu de maintenance au développement ou à la mise en œuvre de solutions de mise à l'échelle automatique. Pour plus d’informations, consultez « À propos des exécuteurs hébergés par GitHub ».

Le projet ARC (actions/actions-runner-controller ) est un autoscaler de runners basé sur Kubernetes. GitHub recommande ARC si l'équipe qui le déploie a des connaissances et une expérience expertes de Kubernetes.

Pour plus d’informations, consultez « À propos d’Actions Runner Controller » et « À propos du support pour Actions Runner Controller ».

Utilisation d’exécuteurs éphémères pour la mise à l’échelle automatique

GitHub recommande d’implémenter la mise à l’échelle automatique avec des exécuteurs auto-hébergés éphémères. La mise à l’échelle automatique avec des exécuteurs auto-hébergés persistants n’est pas recommandée. Dans certains cas, GitHub ne peuvent pas garantir que les travaux ne sont pas affectés aux exécuteurs persistants pendant qu’ils sont arrêtés. Avec les exécuteurs éphémères, cela peut être garanti car GitHub affecte un seul travail à un exécuteur.

Cette approche vous permet de gérer vos exécuteurs en tant que systèmes éphémères, car vous pouvez utiliser l’automatisation pour fournir un environnement propre pour chaque travail. Cela permet de limiter l’exposition de toutes les ressources sensibles des travaux précédents, et permet également d’atténuer le risque qu’un exécuteur compromis reçoive de nouveaux travaux.

Warning

Les fichiers journaux des applications d’exécuteurs pour les exécuteurs éphémères doivent être transmis à une solution de stockage de journaux externe à des fins de dépannage et de diagnostic. Bien qu’il ne soit pas obligatoire de déployer des exécuteurs éphémères, GitHub recommande de s’assurer que les journaux d’exécuteurs sont transmis et conservés en externe avant de déployer une solution de mise à l’échelle automatique d’exécuteurs éphémères dans un environnement de production. Pour plus d’informations, consultez « Surveillance des exécuteurs auto-hébergés et résolution des problèmes ».

Pour ajouter un exécuteur éphémère à votre environnement, incluez le paramètre --ephemeral lors de l’inscription de votre exécuteur à l’aide de config.sh. Par exemple :

./config.sh --url https://github.com/octo-org --token example-token --ephemeral

Le service GitHub Actions désinscrit automatiquement l’exécuteur une fois qu’il a traité un travail. Vous pouvez ensuite créer votre propre automatisation qui efface l’exécuteur une fois qu’il a été désinscrit.

Remarque : Si un travail est étiqueté pour un certain type d’exécuteur, mais qu’aucun exécuteur de ce type n’est disponible, le travail n’échoue pas immédiatement au moment de la mise en file d’attente. Au lieu de cela, le travail reste en file d’attente jusqu’à ce que la période d’expiration de 24 heures expire.

Vous pouvez également créer des exécuteurs juste-à-temps éphémères à l’aide de l’API REST. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les exécuteurs auto-hébergés ».

Contrôle des mises à jour logicielles d’exécuteur sur les exécuteurs auto-hébergés

Par défaut, les exécuteurs auto-hébergés effectuent automatiquement une mise à jour logicielle chaque fois qu’une nouvelle version du logiciel d’exécuteur est disponible. Si vous utilisez des exécuteurs éphémères dans des conteneurs, cela peut entraîner des mises à jour logicielles répétées lorsqu’une nouvelle version de l’exécuteur est publiée. La désactivation des mises à jour automatiques vous permet de mettre à jour la version de l’exécuteur sur l’image conteneur directement selon votre propre calendrier.

Pour désactiver les mises à jour logicielles automatiques et installer vous-même des mises à jour logicielles, spécifiez l’indicateur --disableupdate lors de l’inscription de votre exécuteur à l’aide de config.sh. Par exemple :

./config.sh --url https://github.com/YOUR-ORGANIZATION --token EXAMPLE-TOKEN --disableupdate

Si vous désactivez les mises à jour automatiques, vous devez toujours mettre à jour régulièrement votre version d’exécuteur. Une nouvelle fonctionnalité dans GitHub Actions nécessite des modifications dans le service GitHub Actions et le logiciel d’exécuteur. L’exécuteur peut ne pas être en mesure de traiter correctement les travaux qui exploitent de nouvelles fonctionnalités dans GitHub Actions sans mise à jour logicielle.

Si vous désactivez les mises à jour automatiques, vous serez tenu de mettre à jour votre version de l’exécuteur dans les 30 jours suivant la mise à disposition d’une nouvelle version. Vous souhaiterez peut-être vous abonner aux notifications des nouvelles versions dans le dépôt actions/runner. Pour plus d’informations, consultez « Configuration des notifications ».

Pour obtenir des instructions sur la façon d’installer la dernière version de l’exécuteur, consultez les instructions d’installation de la dernière version.

Warning

Toutes les mises à jour publiées pour le logiciel, y compris les versions majeures, mineures ou les correctifs, sont considérées comme des mises à jour disponibles. 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.

Utilisation de webhooks pour la mise à l’échelle automatique

Vous pouvez créer votre propre environnement de mise à l’échelle automatique à l’aide des charges utiles reçues du webhook workflow_job. Ce webhook est disponible au niveau du dépôt, de l’organisation et de la grande entreprise, et la charge utile de cet événement contient une clé action qui correspond aux étapes du cycle de vie d’un travail de workflow. Par exemple, lorsque les travaux sont queued, in_progress et completed. Vous devez ensuite créer votre propre automatisation de mise à l’échelle en réponse à ces charges utiles de webhook.

Exigences relatives à l’authentification

Vous pouvez inscrire et supprimer des exécuteurs auto-hébergés de dépôt ou d’organisation à l’aide de l’API. Pour vous authentifier auprès de l’API, votre implémentation de mise à l’échelle automatique peut utiliser un jeton d’accès ou une application GitHub.

Votre jeton d’accès nécessite l’étendue suivante :

Pour vous authentifier à l’aide d’une application GitHub, elle doit être affectée des autorisations suivantes :

  • Pour les dépôts, attribuez l’autorisation administration.
  • Pour les organisations, attribuez l’autorisation organization_self_hosted_runners.

Vous pouvez inscrire et supprimer des exécuteurs auto-hébergés au niveau de la grande entreprise à l’aide de l’API. Pour vous authentifier auprès de l’API, votre implémentation de mise à l’échelle automatique peut utiliser un jeton d’accès.

Votre jeton d’accès nécessite l’étendue manage_runners:enterprise.