조직 내 GitHub 호스팅 러너에 대한 프라이빗 네트워킹 구성하기

조직에서 Azure 프라이빗 네트워크와 함께 GitHub-호스트된 러너를 사용하는 방법을 알아봅니다.

누가 이 기능을 사용할 수 있나요?

엔터프라이즈에서 조직의 조직 소유자는 조직 수준에서 GitHub 호스트형 실행기용 Azure 개인 네트워킹을 구성할 수 있습니다.

이 기사에서

GitHub 호스트 실행기를 위한 Azure 비공개 네트워킹 정보

Azure VNET에서 GitHub호스팅된 실행기를 사용하려면 먼저 Azure 리소스를 구성하세요. 그런 다음 , 에서 프라이빗 네트워크 구성을 만듭니다 GitHub.

다음 절차는 두 단계를 모두 안내합니다.

Azure VNET와 함께 GitHub-hosted 러너를 사용할 때 발생하는 일반적인 문제를 해결하는 방법에 대한 자세한 내용은 엔터프라이즈용 GitHub 호스트 실행기를 위한 Azure 비공개 네트워크 구성 문제 해결.을(를) 참조하세요.

참고

기본적으로 엔터프라이즈의 조직은 새 네트워크 구성을 만들 수 없으며 엔터프라이즈 수준 네트워크 구성만 상속할 수 있습니다. 엔터프라이즈 소유자는 엔터프라이즈의 조직이 엔터프라이즈와 독립적인 네트워크 구성을 만들 수 있도록 하는 정책을 설정할 수 있습니다. 자세한 내용은 GitHub에서 호스팅되는 러너를 위한 엔터프라이즈 내 프라이빗 네트워킹 구성을(를) 참조하세요.

Azure 리소스 구성

스크립트를 사용하여 Azure 리소스 구성을 자동화합니다.

필수 조건

  • 구독 기여자 역할 및 네트워크 기여자 역할과 함께 Azure 계정을 사용합니다. 이러한 역할을 사용하면 GitHub.Network 리소스 공급자를 등록하고 서브넷을 위임할 수 있습니다. 자세한 내용은 Azure 설명서의 Azure 기본 제공 역할을 참조하세요.

  • 서브넷을 올바른 사용자와 올바르게 연결하려면 가상 네트워크가 만들어지는 동일한 구독에서 Azure NetworkSettings 리소스를 만들어야 합니다.

  • 리소스 가용성/데이터 보존을 보장하려면 동일한 Azure 지역에 리소스를 만들어야 합니다.

  • 서브넷의 아웃바운드 네트워크 트래픽은 네트워크에서 가로채기를 수행하는 데 사용하는 중간 인증서를 신뢰하도록 Virtual Machines 구성되지 않으므로 TLS 가로채기의 적용을 받지 않아야 합니다.

    TLS 가로채기를 사용해야 하는 경우 사용자 지정 이미지를 통해 중간 인증서를 설치할 수 있습니다. 사용자 지정 이미지 사용을(를) 참조하세요.

  • Azure VNET을 통해 일정 수준의 네트워크 트래픽 제어를 사용하고 DNS/도메인 기반 컨트롤을 사용하는 것이 좋습니다. 이전에 권장하는 IP 주소는 2026년 7월 1일 또는 그 이후에 닫힙니다.

DNS/도메인 제어(권장)

DNS 또는 도메인을 사용해 Azure VNET으로 GitHub호스팅된 실행기의 아웃바운드 액세스를 제어하는 경우, GitHub Actions 기능을 위해 일련의 도메인을 허용 목록에 추가해야 합니다. 네트워크 요구 사항이 변경되면 최신 상태로 유지되는 GitHub 메타 엔드포인트에 GitHub 도메인이 게시되기 때문에 이 방법을 사용하는 것이 좋습니다. 함수별 도메인에 대한 분석은 자체 호스팅 실행기 참조의 "통신" 섹션을 참조하세요.

허용 목록에 추가할 도메인은 https://api.github.com/meta의 GitHub 메타 엔드포인트에서 확인할 수 있습니다. 메타 엔드포인트에 대한 자세한 내용은 메타 데이터에 대한 REST API 엔드포인트을 참조하세요.

메타 엔드포인트에는 다음을 기반으로 허용 목록을 선택할 수 있는 세 개의 섹션이 있습니다.

  • domains.actions_inbound.full_domains: 와일드카드 도메인이 없는 기능에 필요한 GitHub Actions 정확한 도메인의 매우 구체적인 목록입니다.
  • domains.actions: 일부 GitHub소유 도메인이 와일드카드로 표시되지만 다른 도메인이 구체적으로 나열된 중간 도메인 목록입니다.
  • domains.actions_inbound.wildcard_domains: 주로 와일드카드 도메인이 있는 목록입니다. 이는 도메인 변경 관점에서 가장 안정적입니다.

경고

메타 엔드포인트의 필수 도메인은 변경될 수 있습니다. GitHub 는 도메인이 사용되기 전에 적어도 일주일 동안 메타 엔드포인트에 있는지 확인합니다. 메타 엔드포인트는 "마지막으로 업데이트된" 날짜를 제공하지 않으므로 타임스탬프를 사용하여 변경 내용을 검색할 수 없습니다.

보다 구체적인 도메인 목록을 사용하려는 경우 매주 새 도메인을 확인하고 네트워크 제어 시스템을 적절하게 업데이트해야 합니다. 그렇지 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 쿼리를 사용하여 조직 databaseId을(를) 검색하세요. 다음 단계에서 조직 databaseId를 DATABASE_ID 환경 변수 값으로 사용합니다. GraphQL 작업에 대한 자세한 내용은 GraphQL을 사용하여 통화 구성을(를) 참조하세요.

쿼리 변수설명
login조직 계정의 로그인이며 조직의 URL인 https://github.com/organizations/ORGANIZATION_LOGIN을(를) 보면 식별할 수 있습니다.
query(
  $login: String!
){
  organization (login: $login)
  {
    login
    databaseId
  }
}
'
Variables
{
  "login": "ORGANIZATION_LOGIN"
}

또는 다음 컬 명령을 사용하여 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 Enterprisedatabase 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 리소스를 구성한 후에는 조직 수준에서 네트워크 구성. 그런 다음 해당 네트워크 구성을 실행기 그룹에 연결할 수 있습니다.

Azure로 구성된 네트워크 설정을 만들 때 초기 설정은 엔터프라이즈 수준에 있어야 합니다. 이 때문에 databaseId을(를) 가져올 때 해당 단계에서 엔터프라이즈 슬러그를 구성해야 합니다. 조직은 엔터프라이즈가 호스트된 컴퓨팅 네트워킹에 대한 엔터프라이즈 정책을 통해 설정되고 사용하도록 설정된 후에만 자체 네트워크 구성을 만들 수 있습니다. 더 큰 실행기 액세스 제어에서 러너 그룹에 대한 자세한 내용을 확인하세요.

네트워크 구성이 실행기 그룹과 연결되면 해당 그룹의 모든 실행기는 기본 구성에 연결된 Azure VNET에 액세스할 수 있습니다.

필수 조건

에서 네트워크 구성__ 을 추가GitHub Azure 리소스가 구성되었는지 확인합니다. 자세한 내용은 을 참조 하세요.

1. 조직에 대한 새 네트워크 구성 추가

  1. GitHub의 오른쪽 위 모서리에서 프로필 사진을 클릭한 다음, Your organizations를 클릭합니다.

  2. 조직을 클릭하여 선택합니다.

  3. 조직 이름에서 설정을 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

    조직 프로필에 있는 여러 탭의 스크린샷. "설정" 탭이 진한 주황색으로 표시됩니다.

  4. 왼쪽 사이드바에서 호스트된 컴퓨팅 네트워킹을 클릭하세요.

  5. 새 네트워크 구성 드롭다운을 클릭하세요. 그런 다음 Azure 프라이빗 네트워크 클릭합니다.

  6. 네트워크 구성 이름 바꾸기

  7. Azure Virtual Network 추가를 클릭합니다.

  8. 팝업 창에서 개인 네트워킹에 대한 Azure 리소스를 구성할 때 검색한 네트워크 설정 리소스 ID를 입력합니다.

  9. Azure Virtual Network 추가를 클릭합니다.

2. 조직에 대한 러너 그룹 만들기

참고

조직 내 리포지토리에서 실행기 그룹에 액세스하려면 해당 리포지토리가 조직 수준에서 해당 실행기 그룹에 액세스할 수 있어야 합니다. 자세한 내용은 더 큰 실행기 액세스 제어을(를) 참조하세요.

  1. 조직을 위한 새로운 러너 그룹 생성 실행기 그룹을 만드는 방법에 대한 자세한 내용은 더 큰 실행기 액세스 제어에서 확인하세요.
  2. 리포지토리 액세스에 대한 정책을 선택하려면 리포지토리 액세스 드롭다운 메뉴를 선택하고 정책을 클릭합니다. 특정 리포지토리 목록 또는 조직의 모든 리포지토리에 액세스할 수 있도록 실행기 그룹을 구성할 수 있습니다.
  3. 실행기 그룹을 구성하는 동안 "네트워크 구성"에서 드롭다운 메뉴를 사용하여 Azure VNET에 대해 만든 네트워크 구성을 선택합니다.
  4. 그룹 생성을 클릭하여 그룹을 만들고 정책을 적용하세요.

3. 조직 실행기 그룹에 GitHub 호스트 실행기를 추가합니다.

참고

GitHub 호스팅 실행기를 실행기 그룹에 추가할 때, 이전 절차에서 만든 실행기 그룹을 선택합니다.

  1. GitHub 호스트 실행기를 실행기 그룹에 추가합니다. 자세한 내용은 대형 런너 관리하기을(를) 참조하세요.

4. 선택적으로 네트워크 구성 관리

  1. GitHub의 오른쪽 위 모서리에서 프로필 사진을 클릭한 다음, Your organizations를 클릭합니다.

  2. 조직을 클릭하여 선택합니다.

  3. 조직 이름에서 설정을 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

    조직 프로필에 있는 여러 탭의 스크린샷. "설정" 탭이 진한 주황색으로 표시됩니다.

  4. 왼쪽 사이드바에서 호스트된 컴퓨팅 네트워킹을 클릭하세요.

  5. 네트워크 구성을 편집하려면 네트워크 구성 오른쪽에서 을 클릭합니다 . 그런 다음 구성 편집을 클릭하세요.

  6. 네트워크 구성을 사용하지 않도록 설정하려면 네트워크 구성 오른쪽에서 을 클릭합니다 . 비활성화를 클릭하세요.

  7. 네트워크 구성을 삭제하려면 네트워크 구성 오른쪽에서 을 클릭합니다 . 삭제를 클릭합니다.

5. 필요에 따라 네트워크 구성에 장애 조치(failover) 네트워크 추가

참고

VNET 장애 조치(failover)는 공개 미리 보기 상태이며 변경될 수 있습니다.

네트워크 구성에 대한 장애 조치(failover) 네트워크를 구성할 수 있습니다. 장애 조치(failover) 네트워크는 보조 Azure Virtual Network 서브넷으로, 주 서브넷과 다른 Azure 리전에 존재할 수 있습니다. 지역 중단이나 기타 장애로 인해 주 서브넷을 사용할 수 없게 되면, 장애 조치 네트워크를 활성화하여 러너 트래픽을 보조 서브넷을 통해 라우팅함으로써 GitHub Actions 워크플로의 연속성을 유지할 수 있습니다.

VNET 장애 조치(failover)에 대한 핵심 사항들:

  • 장애 조치(failover) 서브넷은 주 서브넷과 다른 Azure 지역에 상주할 수 있습니다.
  • 기본 서브넷과 장애 조치(failover) 서브넷 간 전환은 수동 프로세스입니다. 사용자가 원하는 대로 장애 조치(failover) 네트워크를 사용 또는 미사용으로 설정할 수 있습니다.
  • 장애 조치(failover)를 사용하려면 먼저 기본 서브넷과 장애 조치(failover) 서브넷을 모두 필요한 Azure 리소스(VNET/서브넷, 네트워크 설정 등)로 구성해야 합니다.
  • 장애 조치(failover) 서브넷은 지원되는 지역에 있어야 합니다.

장애 조치(failover) 네트워크를 추가하기 전에 위의 동일한 "Azure 리소스 구성" 절차에 따라 보조 서브넷에 대한 Azure 리소스(VNET, 서브넷, 네트워크 보안 그룹 및 네트워크 설정 리소스)를 구성해야 합니다. 장애 조치(failover) 서브넷은 주 서브넷과 다른 Azure 지역에 있을 수 있습니다.

  1. GitHub의 오른쪽 위 모서리에서 프로필 사진을 클릭한 다음, Your organizations를 클릭합니다.

  2. 조직을 클릭하여 선택합니다.

  3. 조직 이름에서 설정을 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

    조직 프로필에 있는 여러 탭의 스크린샷. "설정" 탭이 진한 주황색으로 표시됩니다.

  4. 왼쪽 사이드바에서 호스트된 컴퓨팅 네트워킹을 클릭하세요.

  5. 장애 조치(failover) 네트워크를 추가할 네트워크 구성 옆에 있는 편집 아이콘()을 클릭합니다. 그런 다음 구성 편집을 클릭하세요.

  6. 클릭하여 장애 조치 네트워크 추가.

  7. 팝업 창에서 보조(장애 조치) Azure 서브넷에 대한 네트워크 설정 리소스 ID를 입력합니다.

  8. Azure Virtual Network 추가를 클릭합니다.

  9. 이제 네트워크 구성에 기본 서브넷과 장애 조치(failover) 서브넷 두 개가 나열되어 있으며, 각각의 기능에 맞게 레이블이 지정됩니다.

6. 옵션으로, 장애 조치(failover) 네트워크를 활성화하거나 비활성화합니다.

장애 조치(failover) 네트워크를 추가한 후에는, 이를 활성화하여 트래픽을 보조 서브넷을 통해 라우팅하거나 비활성화하여 기본 서브넷으로 되돌릴 수 있습니다.

  1. GitHub의 오른쪽 위 모서리에서 프로필 사진을 클릭한 다음, Your organizations를 클릭합니다.

  2. 조직을 클릭하여 선택합니다.

  3. 조직 이름에서 설정을 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

    조직 프로필에 있는 여러 탭의 스크린샷. "설정" 탭이 진한 주황색으로 표시됩니다.

  4. 왼쪽 사이드바에서 호스트된 컴퓨팅 네트워킹을 클릭하세요.

  5. 네트워크 구성 옆에 있는 편집 아이콘()을 클릭합니다. 그런 다음 구성 편집을 클릭하세요.

  6. 장애 조치 네트워크로 전환하려면 장애 조치 VNET 사용을 클릭합니다. 실행기 트래픽은 장애 조치(failover) 서브넷을 통해 라우팅됩니다.

  7. 기본 네트워크로 다시 전환하려면 장애 조치 VNET 사용 안 함을 클릭합니다. 러너 트래픽은 기본 서브넷으로 복귀합니다.

참고

리전에서 장애가 발생하면 GitHub에서 자동으로 장애 조치(failover)를 활성화합니다. 사용자는 감사 로그 이벤트와 이메일을 통해 알림을 받습니다. 중단이 해결되면 기본 서브넷으로 돌아가려면 장애 조치(failover)를 수동으로 사용하지 않도록 설정해야 합니다.

서브넷 삭제

네트워크 설정 리소스를 만들면 제공하는 서브넷에 서비스 연결 링크가 적용됩니다. 이 링크는 GitHub Actions 서비스에서 사용 중인 서브넷이 실수로 삭제되는 것을 방지합니다.

서브넷을 삭제하려면 먼저 이 서비스 연결 링크를 제거해야 합니다. 네트워크 설정 리소스가 삭제되면 서비스 연결 링크는 자동으로 안전하게 제거됩니다.

네트워크 설정 리소스를 삭제하려면 네트워크 설정 리소스를 사용하는 네트워크 구성을 먼저 삭제해야 합니다.

  1. 귀하의 기업으로 이동하세요. 예를 들어 GitHub.com의 Enterprises 페이지에서.

  2. 페이지 맨 위에서 클릭합니다****.

  3. 왼쪽 사이드바에서 호스트된 컴퓨팅 네트워킹을 클릭하세요.

  4. 삭제하려는 서브넷을 사용하는 네트워크 구성을 엽니다.

  5. 네트워크 구성을 사용하여 실행기 그룹 목록을 검토합니다.

  6. 오른쪽 위에서 "" 버튼을 클릭합니다. 그런 다음 구성 삭제를 클릭합니다.

  7. 네트워크 설정 리소스를 삭제하고 서비스 연결 링크를 제거하려면 Azure CLI에서 다음 명령을 사용하여 사용자 고유의 입력을 사용합니다. 자세한 내용은 CLI(Azure 명령줄 인터페이스) 설명서를 참조하세요.

    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

  8. Azure에서 서브넷을 삭제합니다. 자세한 내용은 Microsoft Learn의 서브넷 삭제를 참조하세요.