Premiers pas avec les outils de projet de GitHub - CloudSavvy IT
Agence web » Actualités du digital » Comment exécuter des builds Github Actions sur vos propres serveurs avec des exécuteurs auto-hébergés – CloudSavvy IT

Comment exécuter des builds Github Actions sur vos propres serveurs avec des exécuteurs auto-hébergés – CloudSavvy IT

Les actions Github sont des pipelines d’automatisation qui peuvent être utilisés pour exécuter des tests et des builds CI. Il s’exécute dans le cloud via les serveurs de Github, mais dans certains cas, tels que la compilation intensive de code, vous préférerez peut-être les exécuter sur vos propres nœuds de travail dédiés.

Pourquoi utiliser des runners auto-hébergés ?

L’un des principaux avantages de Github Actions est qu’il est gratuit et bien intégré au système de Github. Faire de nouveaux commits ou balises de release déclenchera directement un pipeline d’action si vous le configurez pour le faire.

Les actions Github sont facturées en « minutes » et les référentiels publics open source ont un nombre illimité de minutes. Si vous travaillez sur un référentiel privé, vous n’en aurez que 2000 ou 3000 avec les plans Github Pro ou Teams. Vous pouvez acheter plus de minutes directement ou passer à Github Enterprise, qui est livré avec 50 000.

Cependant, Github prend également en charge la possibilité d’auto-héberger la machine qui exécute le pipeline. Vous pouvez utiliser n’importe quel type de machine en tant qu’exécuteur auto-hébergé, y compris des machines locales, des serveurs dédiés ou des instances VPS cloud. Cela peut être très utile, surtout si vous avez du matériel de rechange qui traîne.

Cela présente un certain nombre d’avantages au-delà des simples économies de coûts pour les charges de travail à activité élevée. Souvent, la compilation de code peut être une tâche très intensive. Bien que les builds Github Actions ne soient pas nécessairement lents, ils s’exécutent toujours sur un calcul cloud partagé, il peut donc être avantageux pour vous d’exécuter la build sur un serveur dédié hautes performances. Il en va de même pour les applications gourmandes en mémoire qui peuvent nécessiter beaucoup de RAM pour se terminer.

En plus des performances, l’auto-hébergement vous permet également de contrôler l’environnement de la construction. Peut-être avez-vous besoin d’une intégration avec des serveurs ou des logiciels sur site, ou vous devez exécuter un système d’exploitation qui n’est pas disponible avec les exécuteurs par défaut de Github (il prend en charge Linux, Windows et macOS, mais pas les versions spécifiques de Linux en plus d’Ubuntu).

Configuration d’un exécuteur auto-hébergé

La mise en place d’un coureur est assez simple. Fondamentalement, vous devrez installer le logiciel runner sur votre machine et le connecter à Github. Une fois disponible, vous pouvez configurer certaines actions Github pour utiliser votre runner auto-hébergé au lieu de ceux par défaut.

Vous pouvez soit ajouter des coureurs à un référentiel spécifique, soit les ajouter à une organisation Github. Les ajouter à l’échelle de l’organisation est généralement beaucoup plus utile, mais la configuration pour l’un ou l’autre est la même.

Rendez-vous dans les paramètres de votre organisation et sous Actions > Coureurs, ajoutez un nouveau coureur.

Github fournit des étapes pour configurer et installer le coureur ici. Vous pouvez copier coller ces commandes, mais vous pouvez également utiliser une image Docker si vous préférez l’exécuter de cette façon.

La section suivante vous permet de le lier à Github. Cela utilise un jeton généré afin qu’il puisse accéder à votre compte et vérifier le coureur.

./config.sh --url https://github.com/Organization --token XXXXXX

Vous pouvez choisir sur cet écran le nom du coureur, le groupe auquel il est affecté et les étiquettes qui lui sont associées. Ceux-ci peuvent être utilisés pour filtrer les coureurs dans les configurations d’action.

Ensuite, vous devrez démarrer le coureur. Vous voudrez probablement exécuter ceci sous tmux ou configurez un service pour l’exécuter automatiquement.

EN RELATION: Comment ajouter vos propres services à systemd pour une gestion plus facile

./run.sh

Si vous utilisez un référentiel public, la possibilité d’utiliser des runners auto-hébergés est désactivée par défaut. En effet, l’exécution de builds sur votre propre matériel présente un risque de sécurité potentiel si vous exécutez des builds pour des demandes d’extraction tierces. Si vous ne faites pas de builds de demande d’extraction, ce n’est pas un problème et vous pouvez l’activer à partir des paramètres par défaut du « Groupe d’exécution ».

Ensuite, vous pouvez utiliser le self-hosted tag pour que les builds s’exécutent sur ce runner.

Le coureur devrait le ramasser presque immédiatement.

★★★★★