Résolution des problèmes de configuration de la mise en réseau pour les runners hébergés par GitHub dans votre entreprise
Activation de la création de configurations réseau pour les organisations dans un environnement d'entreprise
Par défaut, les organisations d’une entreprise ne peuvent pas créer de nouvelles configurations réseau et héritent uniquement des configurations réseau au niveau de l’entreprise. Les propriétaires d’entreprise peuvent définir une stratégie qui permet aux organisations de l’entreprise de créer des configurations réseau indépendantes de l’entreprise. Pour plus d’informations, consultez « Configuration de la mise en réseau privée pour les exécuteurs hébergés par GitHub dans votre entreprise ».
Configuration des ressources Azure avant de créer une configuration réseau dans GitHub
Vérifiez que vos ressources Azure ont été configurées avant d’ajouter une configuration réseau dans GitHub.
Régions prises en charge
Le GitHub Actions service prend en charge un sous-ensemble de toutes les régions qu’Azure fournit. Pour faciliter la communication entre le GitHub Actions service et votre sous-réseau, votre sous-réseau doit se trouver dans l’une des régions prises en charge.
Remarque
Si vous utilisez résidence de données sur GHE.com, les régions prises en charge sont différentes. Consultez Détails réseau pour GHE.com.
Les régions suivantes sont prises en charge sur GitHub.com.
AustraliaEastBrazilSouthCanadaCentralCanadaEastCentralUsEastAsiaEastUsEastUs2FranceCentralGermanyWestCentralJapanWestKoreaCentralNorthCentralUsNorthEuropeNorwayEastSouthCentralUsSoutheastAsiaSouthIndiaSwedenCentralSwitzerlandNorthUkSouthUkWestWestUsWestUs2WestUs3
La mise en réseau privée Azure prend en charge les exécuteurs GPU dans les régions suivantes.
EastUsNorthCentralUsSouthCentralUsWestUs
La mise en réseau privée Azure prend en charge les exécuteurs arm64 dans les régions suivantes.
CentralUsEastUsEastUs2NorthCentralUsSouthCentralUsWestUsWestUs2WestUs3
Nous lancerons bientôt un processus de demande de support pour de nouvelles régions. Vous pouvez également utiliser le peering global de réseau virtuel pour connecter des réseaux virtuels à travers les régions Azure. Pour plus d’informations, consultez Peering de réseau virtuel dans la documentation Azure.
Le runner n’a pas réussi à se connecter à Internet
GitHub-Les runners hébergés par doivent pouvoir établir des connexions sortantes ver GitHub ainsi que vers d’autres URL nécessaires pour GitHub Actions.
Si GitHub Actions ne peut pas communiquer avec les runners, le pool ne pourra jamais mettre les runners en ligne et aucun travail ne sera pris en charge. Dans ce cas, le pool aura le code d’erreur suivant.
VNetInjectionFailedToConnectToInternet
Pour résoudre ce problème, vérifiez que vous avez configuré vos ressources Azure en fonction des procédures « Configuration de vos ressources Azure ».
L’étendue du déploiement est verrouillée
Vous pouvez placer des verrous sur l’abonnement ou le groupe de ressources Azure, ce qui peut empêcher la création ou la suppression de NIC.
Les verrous qui empêchent la création de NIC ne permettent pas de prendre en charge les travaux, tandis que les verrous qui empêchent la suppression de NIC épuisent l’espace d’adresses du sous-réseau (en continuant à créer des NIC) ou entraînent des temps longs de mise en file d’attente avant attribution (QTA) lorsque le service retente les exceptions de déploiement.
Dans ce cas, le pool aura le code d'erreur suivant.
RunnerDeploymentScopeLocked
Pour résoudre ce problème, supprimez le verrou ou modifiez le sous-réseau que vous utilisez en un sous-réseau sans verrou.
Déploiement bloqué par stratégie
Vous pouvez créer des stratégies sur leur groupe d’administration, leur abonnement, leur groupe de ressources ou leurs ressources individuelles. La stratégie la plus courante exige qu’une ressource ait certaines balises ou qu’elle ait un nom spécifique.
La politique empêchera la création de cartes réseau (NIC), ce qui signifie que le pool ne pourra pas traiter de tâches, car aucune machine virtuelle ne pourra être mise en ligne.
Dans ce cas, le pool aura le code d’erreur suivant.
RunnerDeploymentBlockedByPolicy
Pour résoudre ce problème, supprimez la stratégie ou modifiez le sous-réseau que vous utilisez en un sous-réseau sans verrou.
Le sous-réseau est plein
Les sous-réseaux ont une quantité limitée d’adresses IP à distribuer. Chaque exécuteur consomme une adresse IP. Si le service tente d’effectuer un scale-up au-delà du paramètre de nombre maximal d’exécuteurs, il rencontre des erreurs de déploiement.
Cela affecte la capacité du pool à ajouter des runners supplémentaires. Si la profondeur de la file d’attente est suffisamment élevée, vous pouvez rencontrer une augmentation du temps de file d’attente pour affectation (QTA). Les tâches seront toujours traitées, mais pas au niveau de simultanéité que vous pourriez attendre.
Dans ce cas, le pool présentera le code d'erreur suivant.
VNetInjectionSubnetIsFull
Pour résoudre ce problème, augmentez la taille du sous-réseau que vous utilisez ou réduisez le nombre maximum de runners du pool pour qu’il corresponde à la taille de votre sous-réseau.
Impossible de supprimer un sous-réseau
Dans certains cas, un sous-réseau ne peut pas être supprimé parce qu'un lien d'association de service (SAL) lui est appliqué. Pour plus d’informations, consultez « Configuration de la mise en réseau privée pour les exécuteurs hébergés par GitHub dans votre organisation ».
Si vous devez identifier la ressource de paramètres réseau associée au sous-réseau, vous pouvez exécuter la commande curl suivante.
Pour obtenir un jeton Azure Entra, veuillez vous référer à la documentation Azure. Utilisez la même api-version que vous avez utilisée pour créer la ressource.
curl --request GET \
--url "https://management.azure.com/subscriptions/{subscriptionId}/providers/GitHub.Network/NetworkSettings?api-version={api-version}&subnetId={subnetId}" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer {entra_token}"
NSG ou règles de pare-feu incorrects
Les procédures « Configuration de vos ressources Azure » répertorient les ouvertures requises. Toutefois, vous pouvez avoir des réseaux de production complexes avec plusieurs proxys ou pare-feu en aval.
Si les runners n’arrivent pas à se mettre en ligne, aucune tâche ne sera prise en charge. Votre processus de configuration peut impliquer l’installation de l’application runner et la communication avec le serviceGitHub Actionspour indiquer qu’il est prêt, ainsi que la récupération et l’installation des outils anti-abus. Si l’un de ces processus échoue, le runner ne pourra prendre en charge aucune tâche.
Si vous rencontrez ces problèmes, essayez de configurer une machine virtuelle sur le même sous-réseau que celui que vous utilisez pour la mise en réseau privée avec GitHubdes exécuteurs hébergés. Toutefois, si vous avez un lien d’association de service (SAL) en place, cela n’est pas possible.
Si vous disposez d’un SAL, essayez de configurer un sous-réseau similaire dans le réseau virtuel et placez une machine virtuelle sur ce réseau. Puis tentez d’enregistrer un runner auto-hébergé dessus.
Échec de la charge utile de demande HTTP lors de la configuration des ressources Azure
Lors de l’exécution de la commande en vue de configurer des ressources Azure, vérifiez que vous utilisez la version d’API et la propriété businessId correctes. Si vous utilisez une autre propriété, votre commande peut renvoyer l’erreur suivante.
(HttpRequestPayloadAPISpecValidationFailed) HTTP request payload failed validation against API specification with one or more errors. Please see details for more information.
Si vous rencontrez cette erreur, vous pouvez voir plus d’informations en exécutant la commande à l’aide de l’indicateur ---debug.
Paramètres réseau configurés au mauvais niveau
Si les paramètres réseau ont été configurés à l’aide d’un databaseId d’organisation au lieu d’un databaseId d’entreprise, une erreur se produira. Le message d’erreur indiquera qu’un réseau privé ne peut pas être établi avec l’ID de ressource fourni car il est déjà associé à une entreprise ou une organisation différente. Pour résoudre ce problème, supprimez les paramètres réseau existants et recréez-les en utilisant l’entreprise databaseId.
Le réseau de basculement ne redirige pas le trafic.
Remarque
Le basculement du VNET est en préversion publique et peut être modifié. Le basculement entre le réseau principal et le réseau de secours est un processus progressif. Pendant la transition, les coureurs peuvent courir sur les deux réseaux simultanément. En fonction des tests, la transition complète prend environ 15 minutes. Assurez-vous que les deux sous-réseaux restent accessibles pendant cette période.
Si l’activation du réseau de basculement ne semble pas rediriger le trafic des runners, vérifiez les points suivants :
- Vérifiez que les ressources Azure du sous-réseau de basculement (réseau virtuel/sous-réseau, groupe de sécurité réseau/pare-feu, paramètres réseau) sont correctement configurées. Suivez les mêmes procédures de configuration de vos ressources Azure que celles utilisées pour votre sous-réseau principal.
- Confirmez que le réseau de basculement a été ajouté à la bonne configuration réseau et que cette configuration est associée au groupe de runners approprié
Sous-réseau de basculement inaccessible
Si les runners ne peuvent pas se connecter après l’activation du réseau de basculement, le problème provient probablement des ressources Azure configurées pour le sous-réseau de basculement.
- Assurez-vous que le sous-réseau de basculement dispose des règles NSG ou de pare-feu correctes appliquées, conformément aux exigences énumérées dans les Configuration de la mise en réseau privée pour les exécuteurs hébergés par GitHub dans votre entreprise procédures.
- Vérifiez que le sous-réseau de basculement dispose d’un espace d’adressage IP suffisant pour la simultanéité des runners attendue.
Impossible de revenir au système principal après le basculement déclenché par GitHub
- Accédez à votre configuration réseau dans les paramètres réseau de calcul hébergés .
- Cliquez sur l’icône d’édition en regard de la configuration réseau. Cliquez sur Modifier la configuration.
- Cliquez sur Désactiver le VNET de basculementpour rediriger le trafic des runners vers le sous-réseau principal.
Si vous ne pouvez pas désactiver le basculement, assurez-vous que les ressources Azure du sous-réseau principal sont saines et accessibles. Vérifiez qu’il n’y a pas de pannes en cours dans la région Azure du sous-réseau principal.