Migration d’exécuteurs auto-hébergés vers des exécuteurs hébergés par GitHub

Découvrez comment évaluer votre infrastructure CI actuelle et migrer des flux de travail d’exécuteurs auto-hébergés vers des exécutants hébergés par GitHub.

Dans cet article

Vous pouvez exécuter des workflows sur des runners hébergés par GitHub ou auto-hébergés, ou utiliser un mélange de types de runners.

Ce tutoriel vous montre comment évaluer votre utilisation actuelle des exécuteurs, puis comment migrer efficacement les flux de travail depuis les exécuteurs auto-hébergés vers les exécuteurs hébergés par GitHub.

1. Évaluer votre infrastructure CI actuelle

La migration depuis des runners auto-hébergés vers des runners plus grands hébergés par GitHub commence par une évaluation approfondie de votre infrastructure CI actuelle. Si vous prenez le temps de faire correspondre soigneusement les spécifications et les environnements, vous minimiserez le temps passé à corriger les problèmes lorsque vous commencerez à exécuter des workflows sur des runners différents.

  1. Créez un inventaire de chaque spécification de machine utilisée pour exécuter des flux de travail, notamment les cœurs du processeur, la RAM, le stockage, l’architecture de puce et le système d’exploitation.
  2. Notez si l’un des coureurs fait partie d’un groupe de coureurs ou a une étiquette. Vous pouvez utiliser ces informations pour simplifier la migration des workflows vers de nouveaux runners.
  3. Documentez les images personnalisées et les dépendances préinstallées sur lesquelles reposent les flux de travail, car elles influenceront votre stratégie de migration.
  4. Identifiez les workflows qui ciblent actuellement des runners auto-hébergés, et pourquoi. Par exemple, dans les métriques d’utilisation de GitHub Actions, utilisez l’onglet Jobs et filtrez par balise de coureur (comme self-hosted ou une étiquette personnalisée) pour voir quels référentiels et travaux utilisent cette étiquette. Si vous devez valider des fichiers de flux de travail spécifiques, vous pouvez également utiliser la recherche de code pour rechercher des fichiers de flux de travail qui référencent runs-on: self-hosted ou d’autres étiquettes auto-hébergées.
  5. Identifiez les flux de travail qui accèdent aux ressources de réseau privé (par exemple, les registres de packages internes, les API privées, les bases de données ou les services locaux), car ils peuvent nécessiter une configuration réseau supplémentaire.

2. Faire correspondre vos exigences de traitement aux types d'exécuteurs hébergés par GitHub

GitHub offre des exécuteurs managés dans plusieurs systèmes d’exploitation ( Linux, Windows et macOS) avec des options pour les machines compatibles GPU. Consultez Référence pour les runners de grande taille.

  1. Mappez chaque spécification machine distincte de votre inventaire sur une spécification de runner hébergé par GitHub appropriée.
  2. Notez tous les runners auto-hébergés pour lesquels il n’existe aucune spécification de runner hébergé par GitHub appropriée.
  3. Excluez de vos plans de migration tous les workflows qui doivent continuer à s’exécuter sur des runners auto-hébergés.

3. Estimer les besoins en capacité

Avant de provisionner des exécuteurs hébergés par GitHub, estimez la capacité de calcul nécessaire pour vos flux de travail. L’examen de votre utilisation actuelle de l’exécuteur auto-hébergé vous aide à choisir les tailles d’exécuteur appropriées, à définir des limites de simultanéité et à prévoir les variations potentielles des coûts.

  1. Dans le coin supérieur droit de GitHub, cliquez sur votre photo de profil, puis sur Vos organisations.

  2. Cliquez sur le nom de votre organisation.

  3. Sous le nom de votre organisationl, cliquez sur Insights.

    Capture d’écran de la barre de navigation horizontale d’une organisation. Un onglet, avec une icône de graphique et le texte « Insights », est mis en évidence avec un encadré orange foncé.

  4. Dans le menu de navigation « Insights », cliquez sur Mesures d’utilisation des actions.

  5. Cliquez sur l’onglet qui contient les métriques que vous souhaitez afficher. Consultez À propos des mesures des GitHub Actions.

  6. Examinez les points de données suivants pour estimer la capacité des runners hébergés :

    •      **Nombre total de minutes consommées** : vous aide à estimer la demande de calcul de référence.

    •      **Nombre d’exécutions de flux de travail** : permet d'identifier les pics d'activité qui peuvent nécessiter davantage de concurrence.
    • Distribution des travaux entre les types de système d’exploitation : garantit la mise en service de la combinaison appropriée des exécuteurs Linux, Windows et macOS.
    •           **Étiquettes de runners (onglet Jobs)**  : filtrez par une étiquette de runner pour comprendre où une étiquette est utilisée.

  7. Convertissez vos résultats en plan de capacité :

    • Faites correspondre les workflows à forte utilisation à des tailles de runners plus grands lorsque cela est approprié.
    • Identifiez les flux de travail qui peuvent tirer parti des images prédéfinies ou personnalisées pour réduire le runtime.
    • Estimer la concurrence en déterminant le nombre de tâches qui s'exécutent généralement simultanément.

  8. Notez les lacunes suivantes :

    • Workflows ayant des dépendances strictes non prises en charge par vos images actuelles de runners hébergés.
    • Travaux avec des durées inhabituelles de vie ou des besoins en environnement sur mesure. (Vous aurez peut-être besoin d’images personnalisées pour ces images.)

Votre plan de capacité guide le nombre d’exécuteurs à provisionner, les types d’ordinateurs à utiliser et comment configurer les groupes et stratégies d’exécuteur dans les étapes suivantes.

4. Configurer des groupes de runners et des stratégies

Après avoir estimé vos besoins en capacité, configurez les groupes d'exécuteurs et les stratégies d'accès afin que les exécuteurs hébergés par vos soient disponibles pour les organisations et les flux de travail appropriés.

Configurer les groupes de runners avant l'approvisionnement des runners permet de s'assurer que la migration n'ouvre pas l'accès de manière trop large par inadvertance ou ne crée pas d'augmentations de coûts inattendues.

  1. Créez des groupes d’exécuteurs au niveau de l’entreprise pour définir qui peut utiliser vos exécuteurs hébergés. Consultez Contrôle de l’accès aux exécuteurs plus grands.

    Utilisez des groupes d’exécuteurs pour étendre l’accès par organisation, référentiel ou workflow. Si vous migrez depuis des runners auto-hébergés, envisagez de réutiliser les noms de groupe de runners ou les étiquettes existants lorsque cela est possible. Cela permet aux flux de travail de continuer à fonctionner sans modification lorsque vous basculez vers les exécuteurs hébergés par GitHub.

  2. Ajoutez de nouveaux runners hébergés par GitHub au groupe approprié et définissez des limites de concurrence en fonction des modèles d'utilisation que vous avez identifiés à l'étape 3. Pour plus d’informations sur la mise à l’échelle automatique, consultez Gestion des exécuteurs de plus grande taille.

  3. Passez en revue les paramètres de stratégie pour vous assurer que les runners sont uniquement utilisés par les workflows prévus. Par exemple, restreindre l’utilisation à des référentiels spécifiques ou empêcher les flux de travail non approuvés d’accéder à des types d’ordinateurs plus puissants.

Remarque

Les runners plus grands macOS ne peuvent pas être ajoutés à des groupes de runners et doivent être référencés directement dans vos fichiers de workflow.

5. Configurer des runners hébergés par GitHub

Ensuite, provisionnez vos GitHub runners hébergés en fonction des types de machines et de la capacité que vous avez identifiées précédemment.

  1. Choisissez la taille de l’ordinateur et le système d’exploitation qui correspondent à vos besoins en matière de flux de travail. Pour obtenir des images et des spécifications disponibles, consultez Référence pour les runners de grande taille.

  2. Affectez chaque exécuteur à un groupe d’exécuteurs et configurez des limites d’accès concurrentiel pour contrôler le nombre de travaux pouvant s’exécuter en même temps.

  3. Sélectionnez un type d’image :

    • Utilisez les images gérées par GitHub pour un environnement maintenu et fréquemment mis à jour.
    • Utilisez des images personnalisées lorsque vous avez besoin de dépendances préinstallées pour réduire le temps d’installation. Consultez Utilisation d’images personnalisées.

  4. Appliquez les personnalisations requises, telles que les variables d’environnement, l’installation de logiciels ou les scripts de démarrage. Pour plus d’exemples, consultez Personnalisation des exécuteurs hébergés par GitHub.

  5. Si vous le souhaitez, configurez le réseau privé si les runners doivent accéder aux ressources internes. Consultez Mise en réseau privé avec des exécuteurs hébergés par GitHub.

Configurer les options de connectivité privée

Si vos flux de travail ont besoin d’accéder à des ressources privées (par exemple, des registres de packages internes, des API privées, des bases de données ou des services locaux), choisissez une approche adaptée à vos besoins en matière de réseau et de sécurité.

Configurer la mise en réseau privée Azure

Exécutez des runners hébergés par GitHub à l’intérieur d’un réseau virtuel Azure (VNET) pour un accès sécurisé aux ressources internes.

  1. Créez un réseau virtuel Azure (VNET) et configurez des sous-réseaux et des groupes de sécurité réseau pour vos agents.
  2. Activez la mise en réseau privée Azure pour votre groupe de runners. Consultez Configuration d’un réseau privé pour les exécuteurs hébergé sur GitHub dans votre entreprise
  3. Appliquez la configuration réseau, telle que les groupes de sécurité réseau et les règles de pare-feu, pour contrôler le trafic d’entrée et de sortie.
  4. Mettez à jour le ciblage de flux de travail pour utiliser le groupe d’exécuteurs configuré pour la mise en réseau privée.

Pour obtenir des instructions détaillées, consultez :

  •         [AUTOTITLE](/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization)

  •         [AUTOTITLE](/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/configuring-private-networking-for-github-hosted-runners-in-your-enterprise)

Se connecter via un réseau virtualisé WireGuard

Si la mise en réseau privée Azure n’est pas applicable (par exemple, car votre réseau cible est local ou dans un autre cloud), vous pouvez utiliser une superposition VPN telle que WireGuard pour fournir un accès au niveau du réseau aux ressources privées.

Pour obtenir des instructions et des exemples détaillés, consultez Utilisation de WireGuard pour créer un réseau de superposition.

Utiliser OIDC avec une passerelle API pour l’accès approuvé aux ressources privées

Si vous n’avez pas besoin de l’exécuteur pour rejoindre votre réseau privé, vous pouvez utiliser OIDC pour établir un accès fiable et de courte durée à un service que vous exposez via une passerelle d’API. Cette approche peut réduire le besoin de secrets de longue durée et limiter l’accès réseau aux points de terminaison spécifiques dont votre flux de travail a besoin.

Pour obtenir des instructions et des exemples détaillés, consultez Utilisation d’une passerelle API avec OIDC.

6. Mettre à jour les workflows pour utiliser les nouveaux runners

Une fois que vos runners hébergés par GitHub sont configurés, mettez à jour vos fichiers de flux de travail pour les prendre en compte.

  1. Réutilisez les étiquettes existantes si vous avez affecté vos nouveaux runners aux mêmes noms de groupes de runners que ceux utilisés par vos runners auto-hébergés. Dans ce cas, les workflows utiliseront automatiquement les nouveaux runners sans modification.

  2. Si vous avez créé de nouveaux groupes de runners ou de nouvelles étiquettes, mettez à jour le champ runs-on dans vos fichiers YAML de workflow. Par exemple:

    jobs:
  build:
    runs-on: [github-larger-runner, linux-x64]
    steps:
      - name: Checkout code
        uses: actions/checkout@v5
      - name: Build project
        run: make build

  3. Vérifiez les références codées en dur aux étiquettes auto-hébergées (telles que self-hosted, linux-x64 ou des étiquettes personnalisées) et remplacez-les par les étiquettes de runners hébergés par GitHub appropriées.

  4. Testez chaque workflow mis à jour pour vous assurer qu’il s’exécute correctement sur les nouveaux exécuteurs. Surveillez les problèmes liés aux différences d’environnement ou aux dépendances manquantes.

7. Supprimer les exécuteurs auto-hébergés inutilisés

Une fois vos flux de travail mis à jour et testés sur GitHub exécutants hébergés, supprimez tous les exécutants auto-hébergés qui ne sont plus nécessaires. Cela empêche les travaux de cibler accidentellement une infrastructure obsolète. Consultez Suppression d’exécuteurs auto-hébergés.

Avant de supprimer les runners auto-hébergés, vérifiez que vous avez entièrement migré :

  • Dans les métriques d'utilisation de GitHub Actions, utilisez l’onglet Tâches et filtrez par label de runner (par exemple, self-hosted ou vos labels personnalisés) pour confirmer qu’aucun référentiel ou aucune tâche n’utilise toujours des runners auto-hébergés.