組織内のGitHubホストランナーのプライベート ネットワークの構成

組織内の Azure プライベート ネットワークで GitHubホストランナーを使用する方法について説明します。

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

GitHub Team プランを持つ Organization オーナーは、GitHub ホステッド ランナーの Azure プライベート ネットワークを Organization レベルで構成できます。

この記事で

Azure プライベート ネットワークについて - GitHub ホストランナー向け

Azure VNET で GitHub ホステッド ランナーを使用するには、まず、Azure リソースを構成します。 次に、GitHub にプライベート ネットワーク構成を作成します。

次の手順では、両方のステップを実行できます。

Azure VNET での GitHub ホスト ランナーの使用に関する一般的な issue のトラブルシューティングの詳細については、「組織内の GitHub ホストランナーの Azure プライベートネットワーク設定のトラブルシューティング」を参照してください。

Azure リソースの構成

スクリプトを使用して、Azure リソースの構成を自動化します。

前提条件

  • サブスクリプション投稿者ロールとネットワーク投稿者ロールを持つ Azure アカウントを使用します。 これらのロールを使用すると、GitHub.Network リソースプロバイダーを登録し、サブネットを委任できます。 詳細については、Azure のドキュメントの Azure built-in roles を参照してください。

  • サブネットを適切なユーザーに正しく関連付けるには、仮想ネットワークが作成されるのと同じサブスクリプションに Azure NetworkSettings リソースを作成する必要があります。

  • リソースの可用性/データ所在地を確保するには、同じ Azure リージョンにリソースを作成する必要があります。

  • サブネットからの送信ネットワーク トラフィックは TLS インターセプトの対象にすることはできません。Virtual Machinesは、インターセプトを実行するためにネットワークが使用する中間証明書を信頼するように構成されないためです。

    TLS インターセプトを使用する必要がある場合は、カスタム イメージを使用して中間証明書をインストールできます。 「カスタム イメージの使用」を参照してください。

  • Azure VNET に対して一定レベルのネットワーク トラフィック制御を行い、DNS/ドメイン ベースの制御を使用することをお勧めします。 以前に推奨されていた IP アドレスは、2026 年 7 月 1 日以降に閉じられます。

DNS/ドメイン制御 (推奨)

DNS またはドメインを使用して、Azure VNET で GitHub にホストされるランナーの送信アクセスを制御する場合は、GitHub Actions の機能に必要な一連のドメインを許可リストに追加します。 これは推奨される方法です。ドメインは GitHub メタ エンドポイントで公開されるため、ネットワーク要件の変化に応じて GitHub 最新の状態に保たれるからです。 関数別のドメインの詳細については、 セルフホステッド ランナー リファレンス の「通信」セクションを参照してください。

許可リストに追加するドメインは、GitHub meta エンドポイント（https://api.github.com/meta）で確認できます。 メタ エンドポイントの詳細については、「 メタデータ用 REST API エンドポイント」を参照してください。

メタ エンドポイントには、次の 3 つのセクションに基づいて許可リストを選択できます。

  • domains.actions_inbound.full_domains: ワイルドカード ドメインを使用しない、 GitHub Actions 機能に必要なドメインの非常に具体的な一覧。
  • domains.actions:一部の GitHub所有ドメインがワイルドカードされた中間ドメイン リスト。その他のドメインは特に一覧表示されます。
  • domains.actions_inbound.wildcard_domains: 主にワイルドカードドメインを含むリスト。 ドメイン変更の観点から見ると、これは最も安定しています。

警告

メタ エンドポイントで必要なドメインは変更される可能性があります。 GitHub は、ドメインが使用される前に、少なくとも 1 週間はドメインがメタ エンドポイント上にあることを保証します。 メタ エンドポイントは "最終更新日" を提供しないため、タイムスタンプに依存して変更を検出することはできません。

より具体的なドメイン リストを使用する予定の場合は、毎週新しいドメインを確認し、ネットワーク制御システムを適切に更新する必要があります。または、 GitHub Actions ジョブで意図しない問題が発生する可能性があります。 新しいドメインは少なくとも 1 週間前に発行されるため、週単位のチェックでは、変更を適用してから有効になるまでの十分なリード タイムが残ります。 一部の GitHub ドメインワイルドカードを許容する中間的なリストは、はるかに安定しており、完全なワイルドカードリストでは変更はほとんど生じないはずです。

Azure VNET で DNS/ドメイン制御を行うには、任意のテクノロジを使用できます。 このガイダンスは、基本的な機能に必要な最小限のドメインを対象としています。追加のシナリオでは、許可リスト システムにドメインを追加する必要がある場合があります。

IP アドレス制御

警告

以下の IP ベースの .bicep テンプレートは 閉鎖 されており、2026 年 7 月 1 日以降に削除されます。 DNS/ドメイン ベースの制御への移行をサポートするために引き続き使用できます (上記の「DNS/ドメイン制御」を参照)。 この静的リストが最新の状態に保たれていないため、この IP リスト (Terraform など) をハードコーディングまたはテンプレート化したユーザーは、基になる Azure IP 範囲が変更されたときにトラフィックが壊れるリスクがあります。 このテンプレートが削除される前に、メタ エンドポイント ドメインに移行します。

メモ

適切なサブネット IP アドレスの範囲を決定するには、予想される最大ジョブコンカレンシーに 30% のバッファーを追加することをお勧めします。 たとえば、ネットワーク構成のランナーが最大ジョブコンカレンシー 300 に設定されている場合は、少なくとも 390 のランナーを収容できるサブネット IP アドレスの範囲を使用することをお勧めします。 このバッファーにより、IP アドレスを使い果たすことなく、ジョブの同時実行数を満たすために必要な VM 数の予期しない増加にもネットワークで対応できます。

移行期間中に IP アドレスを使用して送信アクセスを制御する場合は、次の .bicep ファイルを保存します。 そのファイルに actions-nsg-deployment.bicep という名前を付けます。

提供する .bicep ファイルには、Azure VNET で GitHub ホステッド ランナーを使用するための最小限のルール セットが含まれています。 特定のユース ケースにルールを追加する必要がある場合があります。

データ所在地付き GitHub Enterprise Cloudを使用する場合は、AllowOutBoundGitHub セクションに、GHE.comのイングレス IP 範囲も含める必要があります。 「GHE.com のネットワークの詳細」を参照してください。

Bicep
@description('NSG for outbound rules')
param location string
param nsgName string = 'actions_NSG'

resource actions_NSG 'Microsoft.Network/networkSecurityGroups@2017-06-01' = {
  name: nsgName
  location: location
  properties: {
    securityRules: [
      {
        name: 'AllowVnetOutBoundOverwrite'
        properties: {
          protocol: 'TCP'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: 'VirtualNetwork'
          access: 'Allow'
          priority: 200
          direction: 'Outbound'
          destinationAddressPrefixes: []
        }
      }
      {
        name: 'AllowOutBoundActions'
        properties: {
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: '*'
          access: 'Allow'
          priority: 210
          direction: 'Outbound'
          destinationAddressPrefixes: [
            '4.175.114.51/32'
            '20.102.35.120/32'
            '4.175.114.43/32'
            '20.72.125.48/32'
            '20.19.5.100/32'
            '20.7.92.46/32'
            '20.232.252.48/32'
            '52.186.44.51/32'
            '20.22.98.201/32'
            '20.246.184.240/32'
            '20.96.133.71/32'
            '20.253.2.203/32'
            '20.102.39.220/32'
            '20.81.127.181/32'
            '52.148.30.208/32'
            '20.14.42.190/32'
            '20.85.159.192/32'
            '52.224.205.173/32'
            '20.118.176.156/32'
            '20.236.207.188/32'
            '20.242.161.191/32'
            '20.166.216.139/32'
            '20.253.126.26/32'
            '52.152.245.137/32'
            '40.118.236.116/32'
            '20.185.75.138/32'
            '20.96.226.211/32'
            '52.167.78.33/32'
            '20.105.13.142/32'
            '20.253.95.3/32'
            '20.221.96.90/32'
            '51.138.235.85/32'
            '52.186.47.208/32'
            '20.7.220.66/32'
            '20.75.4.210/32'
            '20.120.75.171/32'
            '20.98.183.48/32'
            '20.84.200.15/32'
            '20.14.235.135/32'
            '20.10.226.54/32'
            '20.22.166.15/32'
            '20.65.21.88/32'
            '20.102.36.236/32'
            '20.124.56.57/32'
            '20.94.100.174/32'
            '20.102.166.33/32'
            '20.31.193.160/32'
            '20.232.77.7/32'
            '20.102.38.122/32'
            '20.102.39.57/32'
            '20.85.108.33/32'
            '40.88.240.168/32'
            '20.69.187.19/32'
            '20.246.192.124/32'
            '20.4.161.108/32'
            '20.22.22.84/32'
            '20.1.250.47/32'
            '20.237.33.78/32'
            '20.242.179.206/32'
            '40.88.239.133/32'
            '20.121.247.125/32'
            '20.106.107.180/32'
            '20.22.118.40/32'
            '20.15.240.48/32'
            '20.84.218.150/32'
          ]
        }
      }
      {
        name: 'AllowOutBoundGitHub'
        properties: {
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: '*'
          access: 'Allow'
          priority: 220
          direction: 'Outbound'
          destinationAddressPrefixes: [
            '140.82.112.0/20'
            '143.55.64.0/20'
            '185.199.108.0/22'
            '192.30.252.0/22'
            '20.175.192.146/32'
            '20.175.192.147/32'
            '20.175.192.149/32'
            '20.175.192.150/32'
            '20.199.39.227/32'
            '20.199.39.228/32'
            '20.199.39.231/32'
            '20.199.39.232/32'
            '20.200.245.241/32'
            '20.200.245.245/32'
            '20.200.245.246/32'
            '20.200.245.247/32'
            '20.200.245.248/32'
            '20.201.28.144/32'
            '20.201.28.148/32'
            '20.201.28.149/32'
            '20.201.28.151/32'
            '20.201.28.152/32'
            '20.205.243.160/32'
            '20.205.243.164/32'
            '20.205.243.165/32'
            '20.205.243.166/32'
            '20.205.243.168/32'
            '20.207.73.82/32'
            '20.207.73.83/32'
            '20.207.73.85/32'
            '20.207.73.86/32'
            '20.207.73.88/32'
            '20.217.135.1/32'
            '20.233.83.145/32'
            '20.233.83.146/32'
            '20.233.83.147/32'
            '20.233.83.149/32'
            '20.233.83.150/32'
            '20.248.137.48/32'
            '20.248.137.49/32'
            '20.248.137.50/32'
            '20.248.137.52/32'
            '20.248.137.55/32'
            '20.26.156.215/32'
            '20.26.156.216/32'
            '20.26.156.211/32'
            '20.27.177.113/32'
            '20.27.177.114/32'
            '20.27.177.116/32'
            '20.27.177.117/32'
            '20.27.177.118/32'
            '20.29.134.17/32'
            '20.29.134.18/32'
            '20.29.134.19/32'
            '20.29.134.23/32'
            '20.29.134.24/32'
            '20.87.245.0/32'
            '20.87.245.1/32'
            '20.87.245.4/32'
            '20.87.245.6/32'
            '20.87.245.7/32'
            '4.208.26.196/32'
            '4.208.26.197/32'
            '4.208.26.198/32'
            '4.208.26.199/32'
            '4.208.26.200/32'
            '4.225.11.196/32'
            '4.237.22.32/32'
          ]
        }
      }
      {
        name: 'AllowStorageOutbound'
        properties: {
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: 'Storage'
          access: 'Allow'
          priority: 230
          direction: 'Outbound'
          destinationAddressPrefixes: []
        }
      }
    ]
  }
}

1. 組織のdatabaseIdを入手する

ヒント

クエリを正常に実行するには、トークンに少なくとも read:org アクセス許可が必要です。

次の GraphQL クエリを使用して、Organization databaseId を取得できます。 次の手順では、databaseId 環境変数の値として Organization DATABASE_ID を使用します。 GraphQL の使用について詳しくは、「GraphQLでの呼び出しの作成」をご覧ください。

クエリ変数説明
login組織アカウントのログインは、URL を調べることで確認できます。例えば、組織の URL は https://github.com/organizations/ORGANIZATION_LOGIN にあります。
query(
  $login: String!
){
  organization (login: $login)
  {
    login
    databaseId
  }
}
'
Variables
{
  "login": "ORGANIZATION_LOGIN"
}

代わりに、次の cURL コマンドを使用して databaseId を見つけることもできます。

Shell
curl -H "Authorization: Bearer BEARER_TOKEN" -X POST \
  -d '{ "query": "query($login: String!) { organization (login: $login) { login databaseId } }" ,
        "variables": {
          "login": "ORGANIZATION_LOGIN"
        }
      }' \
https://api.github.com/graphql

2. スクリプトを使用して Azure リソースを構成する

次のスクリプトを使用して、Azure プライベート ネットワーク のサブネットを設定します。 このスクリプトでは、同じリソース グループ内にすべてのリソースが作成されます。

スクリプトを使用するには、プレースホルダー環境変数の値に実際の値を入力し、bash シェルまたはLinux 用 Windows サブシステムからスクリプトを実行します。

メモ

  • actions-nsg-deployment.bicep ファイルを保存した同じディレクトリの次のスクリプトのを実行します。
  • YOUR_AZURE_LOCATION 環境変数を設定するときは、リージョンの名前を使用します。 この値は、リージョンの表示名とは異なります。 名前と表示名のリストを表示するには、az account list-locations -o table を使用します。
  • ネットワーク設定リソースを作成すると、指定したサブネットにサービス関連付けリンクが適用されます。 このリンクにより、GitHub Actions サービスで使用中にサブネットが誤って削除されるのを防ぐことができます。
  • このスクリプトをカスタマイズして、既存のサブネットのネットワークリソースを使用する場合、サブネットが GitHub Actions サービスに委任される前に、サブネットに接続されている既存のネットワーク インターフェイス (NIC) が削除されていることを確認する必要があります。 それ以外の場合は、サービスはサービスの関連付けリンクをサブネットに適用できません。
Bash
#!/bin/bash

# This script creates the following resources in the specified subscription:
# - Resource group
# - Network Security Group rules
# - Virtual network (vnet) and subnet
# - Network Settings with specified subnet and GitHub Organization database ID
#
# It also registers the `GitHub.Network` resource provider with the subscription,
# delegates the created subnet to the Actions service via the `GitHub.Network/NetworkSettings`
# resource type, and applies the NSG rules to the created subnet.

# stop on failure
set -e

#set environment
export AZURE_LOCATION=YOUR_AZURE_LOCATION
export SUBSCRIPTION_ID=YOUR_SUBSCRIPTION_ID
export RESOURCE_GROUP_NAME=YOUR_RESOURCE_GROUP_NAME
export VNET_NAME=YOUR_VNET_NAME
export SUBNET_NAME=YOUR_SUBNET_NAME
export NSG_NAME=YOUR_NSG_NAME
export NETWORK_SETTINGS_RESOURCE_NAME=YOUR_NETWORK_SETTINGS_RESOURCE_NAME
export DATABASE_ID=YOUR_DATABASE_ID
export API_VERSION=2024-04-02

# These are the default values. You can adjust your address and subnet prefixes.
export ADDRESS_PREFIX=10.0.0.0/16
export SUBNET_PREFIX=10.0.0.0/24

echo
echo login to Azure
. az login --output none

echo
echo set account context $SUBSCRIPTION_ID
. az account set --subscription $SUBSCRIPTION_ID

echo
echo Register resource provider GitHub.Network
. az provider register --namespace GitHub.Network

echo
echo Create resource group $RESOURCE_GROUP_NAME at $AZURE_LOCATION
. az group create --name $RESOURCE_GROUP_NAME --location $AZURE_LOCATION

echo
echo Create NSG rules deployed with 'actions-nsg-deployment.bicep' file
. az deployment group create --resource-group $RESOURCE_GROUP_NAME --template-file ./actions-nsg-deployment.bicep --parameters location=$AZURE_LOCATION nsgName=$NSG_NAME

echo
echo Create vnet $VNET_NAME and subnet $SUBNET_NAME
. az network vnet create --resource-group $RESOURCE_GROUP_NAME --name $VNET_NAME --address-prefix $ADDRESS_PREFIX --subnet-name $SUBNET_NAME --subnet-prefixes $SUBNET_PREFIX

echo
echo Delegate subnet to GitHub.Network/networkSettings and apply NSG rules
. az network vnet subnet update --resource-group $RESOURCE_GROUP_NAME --name $SUBNET_NAME --vnet-name $VNET_NAME --delegations GitHub.Network/networkSettings --network-security-group $NSG_NAME

echo
echo Create network settings resource $NETWORK_SETTINGS_RESOURCE_NAME
. az resource create --resource-group $RESOURCE_GROUP_NAME --name $NETWORK_SETTINGS_RESOURCE_NAME --resource-type GitHub.Network/networkSettings --properties "{ \"location\": \"$AZURE_LOCATION\", \"properties\" : { \"subnetId\": \"/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP_NAME/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME\", \"businessId\": \"$DATABASE_ID\" }}" --is-full-object --output table --query "{GitHubId:tags.GitHubId, name:name}" --api-version $API_VERSION

echo
echo To clean up and delete resources run the following command:
echo az group delete --resource-group $RESOURCE_GROUP_NAME

このスクリプトは、作成されたリソースの完全なペイロードを返します。 作成されたリソースのペイロードで返される GitHubId ハッシュ値は、GitHub でネットワーク構成を構成するときに、次の手順で使用するネットワーク設定リソース ID です。

で組織のネットワーク構成を作成する GitHub

Azure リソースを構成した後、Organization レベルでネットワーク構成を作成することで、プライベート ネットワークに Azure Virtual Network (VNET) を使用できます。 その後、そのネットワーク構成をランナー グループに関連付けることができます。

ネットワーク構成がランナー グループに関連付けられると、そのグループ内のすべてのランナーが、基になる構成に接続されている Azure VNET にアクセスできるようになります。

前提条件

GitHub にネットワーク構成を追加する_前に_、Azure リソースが構成されていることを確認します。 詳しくは、「組織内のGitHubホストランナーのプライベート ネットワークの構成」をご覧ください。

1. Organization の新しいネットワーク構成を追加する

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Hosted compute networking](ホストされたコンピューティング ネットワーク) をクリックします。

  5. [New network configuration](新しいネットワーク構成) ドロップダウンをクリックします。 次に、Azureプライベート ネットワーク をクリックします。

  6. ネットワーク構成に名前をつけます。

  7. Azure Virtual Network の追加をクリック。

  8. ポップアップ ウィンドウで、プライベート ネットワーク用にAzure リソースを構成したときに取得したネットワーク設定リソース ID を入力します。

  9. Azure Virtual Network の追加をクリック。

2. 組織のランナーグループを作成する

メモ

organization 内のリポジトリからランナー グループにアクセスできるようにするには、それらのリポジトリが organization レベルでそのランナー グループにアクセスできる必要があります。 詳しくは、「より大きなランナーへのアクセスの制御」をご覧ください。

  1. 組織のための新しいランナーグループを作成します。 ランナー グループの作成方法について詳しくは、「より大きなランナーへのアクセスの制御」をご覧ください。
  2. リポジトリ アクセス のポリシーを選択するには、[リポジトリ アクセス] ドロップダウン メニューを選択し、ポリシーをクリックします。 特定のリポジトリのリスト、または組織内のすべてのリポジトリにアクセスできるようにランナー グループを構成できます。
  3. ランナー グループを構成するときに、[ネットワーク構成] のドロップダウン メニューを使用して、Azure VNET 用に作成したネットワーク構成を選択します。
  4. グループを作成し、ポリシーを適用するには、[Create group](グループの作成) をクリックします。

3. GitHubホストランナーを組織ランナー グループに追加する

メモ

GitHubホストランナーをランナー グループに追加するときは、前の手順で作成したランナー グループを選択します。

  1. GitHubホストランナーをランナー グループに追加します。 詳しくは、「より大きなランナーを管理する」をご覧ください。

4. 必要に応じて、ネットワーク構成を管理する

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Hosted compute networking](ホストされたコンピューティング ネットワーク) をクリックします。

  5. ネットワーク構成を編集するには、ネットワーク構成の右側にある [ ] をクリックします。 その後、[Edit configuration](構成の編集) をクリックします。

  6. ネットワーク構成を無効にするには、ネットワーク構成の右側にある [ ] をクリックします。 次に、[Disable](無効) をクリックします。

  7. ネットワーク構成を削除するには、ネットワーク構成の右側にある [ ] をクリックします。 その後、[削除] をクリックします。

5. 必要に応じて、フェールオーバー ネットワークをネットワーク構成に追加します

メモ

VNET フェールオーバーは パブリック プレビュー であり、変更される可能性があります。

ネットワーク構成用のフェールオーバー ネットワークを構成できます。 フェールオーバー ネットワークはセカンダリ Azure Virtual Network サブネットであり、プライマリ サブネットとは異なる Azure リージョンに存在する可能性があります。 リージョンの停止またはその他の中断によってプライマリ サブネットが使用できなくなった場合は、フェールオーバー ネットワークでランナー トラフィックをセカンダリ サブネット経由でルーティングし、 GitHub Actions ワークフローの継続性を維持できます。

VNET フェールオーバーに関する重要なポイント:

  • フェールオーバー サブネットは、プライマリ サブネットとは異なる Azure リージョンに存在できます。
  • プライマリ サブネットとフェールオーバー サブネットの切り替えは、手動で行います。 フェールオーバー ネットワークは、独自の判断で有効または無効にします。
  • フェールオーバーを使用するには、プライマリ サブネットとフェールオーバー サブネットの両方に必要な Azure リソース (VNET/サブネット、ネットワーク設定など) を構成する必要があります。
  • フェールオーバー サブネットは 、サポートされているリージョンに存在する必要があります。

フェールオーバー ネットワークを追加する前に、上記と同じ「Azure リソースの構成」手順に従って、セカンダリ サブネットの Azure リソース (VNET、サブネット、ネットワーク セキュリティ グループ、ネットワーク設定リソース) を構成していることを確認します。 フェールオーバー サブネットは、プライマリ サブネットとは異なる Azure リージョンに配置できます。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Hosted compute networking](ホストされたコンピューティング ネットワーク) をクリックします。

  5. フェールオーバー ネットワークを追加するネットワーク構成の横にある編集アイコン () をクリックします。 その後、[Edit configuration](構成の編集) をクリックします。

  6. [ フェールオーバー ネットワークの追加] をクリックします。

  7. ポップアップ ウィンドウで、セカンダリ (フェールオーバー) Azure サブネットのネットワーク設定リソース ID を入力します。

  8. Azure Virtual Network の追加をクリック。

  9. ネットワーク構成に、プライマリとフェールオーバーの 2 つのサブネットが一覧表示され、それに応じてラベルが付けられます。

6. 必要に応じて、フェールオーバー ネットワークを有効または無効にする

フェールオーバー ネットワークを追加した後、セカンダリ サブネット経由でトラフィックをルーティングできるようにしたり、無効にしてプライマリ サブネットに戻ったりすることができます。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Hosted compute networking](ホストされたコンピューティング ネットワーク) をクリックします。

  5. ネットワーク構成の横にある編集アイコン () をクリックします。 その後、[Edit configuration](構成の編集) をクリックします。

  6. フェールオーバー ネットワークに切り替えるには、[ フェールオーバー VNET を有効にする] をクリックします。 ランナー トラフィックは、フェールオーバー サブネット経由でルーティングされます。

  7. プライマリ ネットワークに戻すには、[ フェールオーバー VNET を無効にする] をクリックします。 ランナー トラフィックはプライマリ サブネットに戻ります。

メモ

GitHubがリージョンの停止時にフェールオーバーを自動的に有効にする場合、監査ログイベントと電子メールで通知されます。 障害が解決されたときにプライマリ サブネットに戻るために、フェールオーバーを手動で無効にする必要があります。

サブネットの削除

ネットワーク設定リソースを作成すると、指定したサブネットにサービス関連付けリンクが適用されます。 このリンクにより、GitHub Actions サービスで使用中にサブネットが誤って削除されるのを防ぐことができます。

サブネットを削除するには、まずサービスのアソシエーション リンクを削除する必要があります。 ネットワーク設定リソースが削除されると、サービスのアソシエーション リンクは自動で安全に削除されます。

ネットワーク設定リソースを削除するには、それを使用するネットワーク構成を最初に削除する必要があります。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Hosted compute networking](ホストされたコンピューティング ネットワーク) をクリックします。

  5. 削除するサブネットを使用しているネットワーク構成を開きます。

  6. ネットワーク構成を使用してランナー グループの一覧を確認します。

  7. 右上隅にある "" ボタンをクリックします。 そして、[構成の削除] をクリックします。

  8. ネットワーク設定リソースを削除し、サービスのアソシエーション リンクを削除するには、Azure CLI で次のコマンドを使用して自分で入力します。 詳細については、ドキュメント『Azure コマンド ライン インターフェイス (CLI)』を参照してください。

    Bash
    az account set --subscription $SUBSCRIPTION_ID
az resource delete -g $RESOURCE_GROUP_NAME --name $NETWORK_SETTINGS_RESOURCE_NAME --resource-type 'GitHub.Network/networkSettings' --api-version $API_VERSION

  9. Azure でサブネットを削除します。 詳細については、Microsoft Learn の「サブネットの削除」を参照してください。