조직에서 GitHub 호스트형 실행기의 개인 네트워킹 구성 문제를 해결하는 방법
GitHub에서 네트워크 구성을 생성하기 전에 Azure 리소스를 구성합니다.
에서 네트워크 구성__ 을 추가GitHub Azure 리소스가 구성되었는지 확인합니다.
지원되는 지역
이 GitHub Actions 서비스는 Azure에서 제공하는 모든 지역의 하위 집합을 지원합니다. 서비스와 서브넷 간의 통신을 GitHub Actions 용이하게 하려면 서브넷이 지원되는 지역 중 하나에 있어야 합니다.
참고
GHE.com에서 데이터의 저장 위치을 사용할 경우, 지원되는 지역이 다릅니다. GHE.com의 네트워크 세부 정보을(를) 참조하세요.
에서 지원 GitHub.com되는 지역은 다음과 같습니다.
AustraliaEastBrazilSouthCanadaCentralCanadaEastCentralUsEastAsiaEastUsEastUs2FranceCentralGermanyWestCentralJapanWestKoreaCentralNorthCentralUsNorthEuropeNorwayEastSouthCentralUsSoutheastAsiaSouthIndiaSwedenCentralSwitzerlandNorthUkSouthUkWestWestUsWestUs2WestUs3
Azure 프라이빗 네트워킹은 다음 지역에서 GPU 실행기를 지원합니다.
EastUsNorthCentralUsSouthCentralUsWestUs
Azure 개인 네트워킹은 다음 지역에서 arm64 실행기를 지원합니다.
CentralUsEastUsEastUs2NorthCentralUsSouthCentralUsWestUsWestUs2WestUs3
곧 새 지역에 대한 지원을 요청하는 프로세스를 시작할 예정입니다. 또한 글로벌 가상 네트워크 피어링을 사용하여 Azure 지역 간에 가상 네트워크를 연결할 수도 있습니다. 자세한 내용은 Azure 설명서의 가상 네트워크 피어링을 참조하세요.
실행기가 인터넷에 연결하지 못함
GitHub
호스트 실행기는 GitHub뿐만 아니라 GitHub Actions에 필요한 다른 URL에 대한 아웃바운드 연결도 할 수 있어야 합니다.
GitHub Actions가 주자들과 통신할 수 없으면, 수영장은 주자들을 온라인으로 가져오지 못하고 그 결과 작업이 처리되지 않을 것입니다. 이 경우 풀에는 다음과 같은 오류 코드가 있습니다.
VNetInjectionFailedToConnectToInternet
이 문제를 해결하려면 "Azure 리소스 구성" 절차에 따라 Azure 리소스를 구성해야 합니다.
배포 범위가 잠겨 있음
Azure 구독 또는 리소스 그룹에 잠금을 설정하여 NIC 생성 또는 삭제를 방지할 수 있습니다.
NIC 생성을 방지하는 잠금은 작업을 처리하지 못합니다. 반면에 NIC 삭제를 방지하는 잠금은 NIC를 계속 생성하여 서브넷 주소 공간을 소모하거나, 서비스가 배포 예외를 계속 시도하면서 대기열 할당(QTA) 시간이 길어집니다.
이 경우 풀에는 다음과 같은 오류 코드가 있습니다.
RunnerDeploymentScopeLocked
이 문제를 해결하려면 잠금을 제거하거나 사용 중인 서브넷을 잠금 없이 하나의 서브넷으로 변경합니다.
정책에 의해 차단된 배포
관리 그룹, 구독, 리소스 그룹 또는 개별 리소스에 정책을 만들 수 있습니다. 가장 일반적인 정책은 리소스에 특정 태그가 있거나 특정 이름을 갖도록 요구하는 것입니다.
이 정책은 NIC 생성을 차단하므로, VM이 온라인 상태가 될 수 없어 풀이 작업을 수신하지 못하게 됩니다.
이 경우 풀에는 다음과 같은 오류 코드가 있습니다.
RunnerDeploymentBlockedByPolicy
이 문제를 해결하려면 정책을 제거하거나 사용 중인 서브넷을 정책 없이 하나의 서브넷으로 변경합니다.
서브넷이 가득 찼습니다.
서브넷에는 배포할 IP 주소의 양이 제한되어 있습니다. 각 실행기는 하나의 IP 주소를 사용합니다. 서비스가 최대 실행기 수 설정을 초과하여 강화하려고 하면 배포 오류가 발생합니다.
이는 추가 러너를 추가하는 풀의 기능에 영향을 줍니다. 대기열의 처리 대기 시간이 충분한 경우, 대기열에서 할당까지 걸리는 시간(QTA)이 늘어날 수 있습니다. 작업은 계속 처리되지만 사용자가 기대할 수 있는 수준의 동시성에는 미치지 못합니다.
이 경우 풀에는 다음과 같은 오류 코드가 있습니다.
VNetInjectionSubnetIsFull
이 문제를 해결하려면 사용 중인 서브넷의 크기를 늘리거나 서브넷 크기와 일치하도록 풀의 최대 실행기 수를 줄입니다.
서브넷을 삭제할 수 없음
경우에 따라 서브넷에 SAL(서비스 연결 링크)이 적용되어 있으므로 삭제할 수 없습니다. 자세한 내용은 조직 내 GitHub 호스팅 러너에 대한 프라이빗 네트워킹 구성하기을(를) 참조하세요.
서브넷과 연결된 네트워크 설정 리소스를 식별해야 하는 경우 다음 curl 명령을 실행할 수 있습니다.
Azure Entra 토큰을 가져오려면 Azure 설명서를 참조하세요. 리소스를 만드는 데 사용한 것과 동일한 api-version을 사용합니다.
curl --request GET \
--url "https://management.azure.com/subscriptions/{subscriptionId}/providers/GitHub.Network/NetworkSettings?api-version={api-version}&subnetId={subnetId}" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer {entra_token}"
잘못된 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 플래그를 사용하여 명령을 실행하여 자세한 정보를 볼 수 있습니다.
잘못된 수준에서 구성된 네트워크 설정
엔터프라이즈 databaseId 대신 조직의 databaseId을(를) 사용하여 네트워크 설정을 구성한 경우 오류가 발생합니다. 오류 메시지는 개인 네트워크가 이미 다른 엔터프라이즈 또는 조직과 연결되어 있으므로 제공된 리소스 ID를 사용하여 설정할 수 없음을 나타냅니다. 이 문제를 해결하려면 기존 네트워크 설정을 삭제하고 엔터프라이즈 databaseId을(를) 사용하여 다시 만듭니다.
트래픽이 전환되지 않는 장애 조치(failover) 네트워크
참고
VNET 장애 조치(failover)는 공개 미리 보기 상태이며 변경될 수 있습니다. 기본 네트워크와 장애 조치(failover) 네트워크 간 전환은 점진적인 프로세스입니다. 주자들은 전환 중에 두 네트워크에서 동시에 뛸 수 있습니다. 테스트에 따라 전체 전환에는 약 15분이 걸립니다. 이 기간 동안 두 서브넷에 계속 액세스할 수 있는지 확인합니다.
장애 조치(failover) 네트워크를 사용하도록 설정해도 런너 트래픽의 경로가 변경되지 않는 경우 다음을 확인합니다.
- 장애 조치 서브넷의 Azure 리소스(VNET/서브넷, NSG/방화벽, 네트워크 설정)가 올바르게 구성되었는지 확인합니다. 기본 서브넷에 사용되는 것과 동일한 "Azure 리소스 구성" 절차를 따릅니다.
- 장애 조치(failover) 네트워크가 올바른 네트워크 구성에 추가되었고 구성이 적절한 실행기 그룹과 연결되어 있는지 확인합니다.
장애 조치(failover) 서브넷에 연결할 수 없음
장애 조치(failover) 네트워크를 활성화한 후 러너가 연결할 수 없는 경우, 장애 조치(failover) 서브넷에 대해 구성된 Azure 리소스에 문제가 있을 가능성이 큽니다.
- 장애 조치(failover) 서브넷에 GitHub에서 호스팅되는 러너를 위한 엔터프라이즈 내 프라이빗 네트워킹 구성 프로시저에 나열된 요구 사항과 일치하는 올바른 NSG 또는 방화벽 규칙이 적용되었는지 확인합니다.
- 장애 조치(failover) 서브넷에 예상되는 실행기 동시 실행 수를 수용하기에 충분한 IP 주소 공간이 있는지 확인하세요.
GitHub가 시작한 장애 조치 후 주(primary)로 다시 전환할 수 없음
-
**호스트된 컴퓨팅 네트워킹** 설정에서 네트워크 구성으로 이동합니다. - 네트워크 구성 옆에 있는 편집 아이콘을 클릭합니다. 그런 다음 구성 편집을 클릭하세요.
- 실행기 트래픽을 주 서브넷으로 되돌리려면 장애 조치(failover) VNET 비활성화를 클릭하세요.
장애 조치(failover)를 사용하지 않도록 설정할 수 없는 경우 기본 서브넷의 Azure 리소스가 정상 상태이고 액세스할 수 있는지 확인합니다. 주 서브넷의 Azure 지역에 지속적인 중단이 없는지 확인합니다.