組織内の GitHub ホストランナーの Azure プライベート ネットワーク構成のトラブルシューティング

Azure VNET で GitHub ホストランナーを使用するための Azure プライベート ネットワーク構成を作成する際の一般的な問題を修正する方法を説明します。

この機能を使用できるユーザーについて

GitHub Team プランを使用している組織は、組織レベルで GitHub ホストランナーを構成できます。

組織内の GitHub でホストされるランナーのプライベート ネットワーク構成のトラブルシューティング

GitHub

でネットワーク構成を作成する前に Azure リソースを構成する

GitHub にネットワーク構成を追加する_前に_、Azure リソースが構成されていることを確認します。

サポートされているリージョン

GitHub Actions サービスは、Azure が提供するすべてのリージョンのサブセットをサポートします。 GitHub Actions サービスとサブネットの間のコミュニケーションを支援するには、次のサポートされているリージョンのいずれかに、サブネットが存在する必要があります。

  • EastUs
  • EastUs2
  • WestUs2
  • AustraliaEast
  • CentralUs
  • FranceCentral
  • NorthEurope
  • NorwayEast
  • SoutheastAsia
  • SwitzerlandNorth
  • UkSouth

Azure プライベート ネットワークは、次のリージョンの GPU ランナーをサポートしています。

  • EastUs
  • WestUs
  • NorthCentralUs
  • SouthCentralUs

また、Azure リージョン間で仮想ネットワークを接続するのに、グローバル仮想ネットワーク ピアリングを使用します。 詳細情報については、Azure ドキュメントの「仮想ネットワーク ピアリング」を参照してください。

ランナーがインターネットに接続できませんでした

GitHub ホステッド ランナーは、GitHub.com への送信接続と、GitHub Actions に必要なその他の URL を確立できる必要があります。

GitHub Actions がランナーと通信できない場合、プールはランナーをオンラインにすることはできないため、ジョブは取得されません。 プールには次のエラー コードが表示されます。

VNetInjectionFailedToConnectToInternet

これを修正するには、「Azure リソースの構成」の手順に従って Azure リソースを構成していることを確認します。詳細については、「組織内の GitHub でホストされるランナーのプライベート ネットワークの構成」を参照してください。

デプロイ スコープがロックされている

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 フラグを使用してコマンドを実行すると、詳細情報を確認できます。