Dépannage des configurations réseau privé Azure pour les exécuteurs hébergés par GitHub dans votre organisation.

Découvrez comment résoudre les problèmes courants lors de la création de configurations réseau privé Azure pour utiliser des exécuteurs hébergés GitHub avec un VNET Azure.

Qui peut utiliser cette fonctionnalité ?

Les propriétaires d’organisation des organisations d’une entreprise peuvent configurer la mise en réseau privée Azure pour les exécuteurs hébergés par GitHub au niveau de l’organisation.

Dépannage de la configuration réseau privé pour les exécuteurs hébergés par GitHub dans votre organisation

Activation de la création des configurations réseau pour les organisations d’une 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 d’un réseau privé pour les exécuteurs hébergé sur GitHub dans votre entreprise ».

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, celui-ci doit se trouver dans l'une des régions prises en charge.

Note

Si vous utilisez différente sur GHE.com, les régions prises en charge sont différentes. Consultez « Détails du réseau pour GHE.com ».

Les régions suivantes sont prises en charge par GitHub.com.

  • EastUs
  • EastUs2
  • WestUs2
  • WestUs3
  • CentralUs
  • NorthCentralUs
  • AustraliaEast
  • JapanEast
  • FranceCentral
  • GermanyWestCentral
  • NorthEurope
  • NorwayEast
  • SwedenCentral
  • SwitzerlandNorth
  • UkSouth
  • SoutheastAsia
  • KoreaCentral

La mise en réseau privée Azure prend en charge les exécuteurs GPU dans les régions suivantes.

  • EastUs
  • WestUs
  • NorthCentralUs

La mise en réseau privée Azure prend en charge les exécuteurs arm64 dans les régions suivantes.

  • EastUs
  • EastUs2
  • WestUs2
  • WestUs3
  • NorthCentralUs

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.