Skip to main content

엔터프라이즈의 GitHub 호스트형 실행기에 대한 Azure 개인 네트워크 구성 문제 해결

Azure VNET에서 GitHub 호스트형 실행기를 사용하도록 Azure 개인 네트워크 구성을 생성하는 동안 발생하는 일반적인 문제를 해결하는 방법에 대해 알아봅니다.

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

Enterprise owners can configure private networking for GitHub-hosted runners at the enterprise level.

엔터프라이즈의 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 주소의 양이 제한되어 있습니다. 각 실행기는 하나의 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 플래그를 사용하여 명령을 실행하여 자세한 정보를 볼 수 있습니다.