Dépannage de la configuration réseau privé pour les exécuteurs hébergés par GitHub dans votre organisation
Configuration de ressources Azure avant la création d’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 service GitHub Actions prend en charge un sous-ensemble de toutes les régions qu’Azure fournit. Pour faciliter la communication entre le service GitHub Actions et votre sous-réseau, votre sous-réseau doit se trouver dans l’une des régions prises en charge suivantes.
EastUsEastUs2WestUs2WestUs3CentralUsNorthCentralUsAustraliaEastJapanEastFranceCentralGermanyWestCentralNorthEuropeNorwayEastSwedenCentralSwitzerlandNorthUkSouthSoutheastAsiaKoreaCentral
La mise en réseau privée Azure prend en charge les exécuteurs GPU dans les régions suivantes.
EastUsWestUsNorthCentralUs
La mise en réseau privée Azure prend en charge les exécuteurs arm64 dans les régions suivantes.
EastUsEastUs2WestUs2WestUs3NorthCentralUs
Si votre région souhaitée n’est pas prise en charge, envoyez une demande de nouvelle disponibilité de région dans ce formulaire GitHub. Vous pouvez également utiliser l’appairage de réseaux virtuels mondiaux pour connecter des réseaux virtuels entre les différentes régions Azure. Pour plus d’informations, consultez le document Peering de réseau virtuel dans la documentation Azure.
L’exécuteur n’a pas pu se connecter à Internet
GitHub
- les exécuteurs hébergés doivent être en mesure d’établir des connexions sortantes à GitHub ainsi que d’autres URL nécessaires pour GitHub Actions.
Si GitHub Actions ne peut pas communiquer avec les exécuteurs, le poule ne pourra jamais mettre en ligne les exécuteurs et aucun travail ne sera récupéré. Dans ce cas, le poule 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 parviennent pas à récupérer des travaux, tandis que les verrous qui empêchent la suppression de NIC épuisent l’espace d’adressage du sous-réseau (en continuant de créer des NIC) ou présentent des temps d’affectation de file d’attente (QTA) élevés lorsque le service effectue une nouvelle tentative d’exceptions de déploiement.
Dans ce cas, le poule 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 stratégie empêche la création de NIC, ce qui signifie que le poule ne récupère pas les travaux, car aucune machine virtuelle ne peut être mise en ligne.
Dans ce cas, le poule 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 a un impact sur la capacité du poule à ajouter d’autres exécuteurs. Si la profondeur de la file d’attente est suffisamment élevée, vous pouvez rencontrer une augmentation des temps d’affectation de file d’attente (QTA). Les travaux seront toujours traités, mais pas à un niveau de concurrence que vous pouvez attendre.
Dans ce cas, le poule aura 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 maximal d’exécuteurs du poule pour qu’il corresponde à la taille de votre sous-réseau.
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.
S’il n’est pas possible de mettre les exécuteurs en ligne, aucun travail ne sera récupéré. Votre processus d’installation peut impliquer la configuration de l’application d’exécuteur et la communication avec le service GitHub Actions pour indiquer qu’elle est prête, ainsi que la récupération et l’installation d’outils de lutte contre les abus. Si l’un de ces processus échoue, l’exécuteur ne peut pas récupérer de travaux.
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 les exécuteurs hébergés par GitHub. 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. Ensuite, essayez d’y inscrire un exécuteur auto-hébergé.
É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.