企業内の GitHub でホストされるランナーのプライベート ネットワーク構成のトラブルシューティング
Enterprise 内の Organization のネットワーク構成の作成を有効にする
既定では、Enterprise 内の Organization は新しいネットワーク構成を作成できず、Enterprise レベルのネットワーク構成を継承するだけです。 Enterprise オーナーは、Enterprise 内の Organization が Enterprise から独立したネットワーク構成を作成できるようにするポリシーを設定できます。 詳しくは、「企業内の GitHub ホストランナーのプライベート ネットワークの構成」を参照してください。
GitHub
でネットワーク構成を作成する前に Azure リソースを構成する
GitHub にネットワーク構成を追加する_前に_、Azure リソースが構成されていることを確認します。
サポートされているリージョン
GitHub Actions サービスは、Azure が提供するすべてのリージョンのサブセットをサポートします。 GitHub Actions サービスとサブネットの間の通信を容易にするには、サブネットがサポートされているリージョンのいずれかに存在している必要があります。
Note
GHE.com で データ所在地が を使う場合は、サポートされているリージョンが異なります。 「GHE.com のネットワークの詳細」を参照してください。
GitHub.com では、次のリージョンがサポートされています。
EastUsEastUs2WestUs2WestUs3CentralUsNorthCentralUsAustraliaEastJapanEastFranceCentralGermanyWestCentralNorthEuropeNorwayEastSwedenCentralSwitzerlandNorthUkSouthSoutheastAsiaKoreaCentral
Azure プライベート ネットワークは、次のリージョンの GPU ランナーをサポートしています。
EastUsWestUsNorthCentralUs
Azure プライベート ネットワークは、次のリージョンで arm64 ランナーをサポートしています。
EastUsEastUs2WestUs2WestUs3NorthCentralUs
希望するリージョンがサポート対象になっていない場合は、この GitHub フォームで新しいリージョンの可用性に関する要求を送信してください。 また、Azure リージョン間で仮想ネットワークを接続するのに、グローバル仮想ネットワーク ピアリングを使用します。 詳細情報については、Azure ドキュメントの「仮想ネットワーク ピアリング」を参照してください。
ランナーがインターネットに接続できませんでした
GitHub ホスト型ランナーは、GitHub への送信接続の他に、GitHub Actions に必要なその他の URL を確立できるようにする必要があります。
GitHub Actions がランナーと通信できない場合、プールはランナーをオンラインにすることはできないため、ジョブは取得されません。 プールには次のエラー コードが表示されます。
VNetInjectionFailedToConnectToInternet
これを修正するには、「Azure リソースの構成」の手順に従って Azure リソースを構成していることを確認します。
デプロイ スコープがロックされている
Azure サブスクリプションまたはリソース グループにロックを設定すると、NIC の作成や削除を妨げる可能性があります。
NIC の作成を妨げるロックによりジョブの取得に失敗します。一方、NIC の削除を妨げるロックは、(NIC の作成を続けることによって) サブネット アドレス スペースを使い果たすか、サービスがデプロイメント例外を再試行するときに割り当てキュー (QTA) 時間が長くなります。
プールには次のエラー コードが表示されます。
RunnerDeploymentScopeLocked
これを修正するには、ロックを削除するか、使用しているサブネットをロックのないサブネットに変更します。
ポリシーによってブロックされたデプロイ
管理グループ、サブスクリプション、リソース グループ、または個々のリソースに対してポリシーを作成できます。 最も一般的なポリシーは、リソースが特定のタグを持つか、特定の名前を持つ必要があることです。
このポリシーでは NIC の作成が禁止されます。つまり、VM をオンラインにできないので、プールはジョブを取得しません。
プールには次のエラー コードが表示されます。
RunnerDeploymentBlockedByPolicy
この問題を解決するには、ポリシーを削除するか、使用しているサブネットをポリシーのないサブネットに変更します。
サブネットが満杯
サブネットには、配布する IP アドレスの数が限られています。 各ランナーは、1 つの IP アドレスを使用します。 サービスが最大ランナー数の設定を超えてスケールアップしようとすると、デプロイ エラーが発生します。
これは、プールがランナーを追加する機能に影響します。 キューの深さが大きい場合は、キューからの割り当て (QTA) 時間が長くなる可能性があります。 ジョブは引き続き処理されますが、予想されるコンカレンシーレベルでは処理されません。
プールには次のエラー コードが表示されます。
VNetInjectionSubnetIsFull
これを修正するには、使用しているサブネットのサイズを増やすか、サブネット サイズに合わせてプールの最大ランナー数を減らします。
不適切な NSG またはファイアウォール規則
「Azure リソースの構成」の手順では、必要な開始を一覧表示します。 ただし、複数のダウンストリーム プロキシまたはファイアウォールを含む複雑な運用ネットワークである可能性があります。
ランナーがオンラインにならない場合、ジョブは実行されません。 セットアップ プロセスには、ランナー アプリケーションを設定し、準備ができていると示すために GitHub Actions サービスへの通信、および悪用防止ツールの取得とインストールが含まれる場合があります。 これらのプロセスのいずれかが失敗した場合、ランナーはジョブを選択できません。
これらの問題が発生している場合は、GitHub ホステッド ランナーを使用したプライベート ネットワークに使用しているのと同じサブネット上に仮想マシンを設定してみてください。 ただし、サービス関連付けリンク (SAL) が設定されている場合、これは不可能です。
SAL が設定されている場合は、仮想ネットワークで同様のサブネットを設定し、そのネットワークに仮想マシンを配置してみてください。 その後、セルフホステッド ランナーの登録を試みます。
Azure リソースを構成するときの HTTP 要求ペイロードエラー
コマンドを実行して Azure リソースを構成するときは、正しい API バージョンと businessId プロパティを使用していることを確認します。 別のプロパティを使用している場合、コマンドによって次のエラーが返されることがあります。
(HttpRequestPayloadAPISpecValidationFailed) HTTP request payload failed validation against API specification with one or more errors. Please see details for more information.
このエラーが発生した場合は、---debug フラグを使用してコマンドを実行すると、詳細情報を確認できます。