About using GitHub-hosted runners in your Azure Virtual Network

이 문서의 내용

You can create GitHub-hosted runners in your Azure Virtual Network(s) (VNET).

About using GitHub-hosted runners in your Azure Virtual Network (VNET)

Notes:

  • Using GitHub-hosted runners with an Azure VNET is in beta and subject to change.
  • Only 4-64 CPU Ubuntu and Windows runners are supported with Azure VNET. For more information on these runner types, see "대규모 실행기 정보."
  • Supported regions include East US, East US 2, and West US 2. To request support for a region that is not in this list, fill out the region request form.

Azure 및 GitHub Enterprise Cloud을(를) 사용하면 Azure VNET에서 GitHub 호스트형 실행기를 만들 수 있습니다. 이렇게 하면 실행기 네트워킹 정책의 모든 권한을 제공하면서 CI/CD의 GitHub관리 인프라를 활용할 수 있습니다. Azure VNET에 대한 자세한 내용은 Azure 문서의 Azure Virtual Network란?을 참조하세요.

You can connect multiple VNET-subnet pairs to GitHub.com and manage private resource access for your runners via runner groups. For more information about runner groups, see "더 큰 실행기 액세스 제어."

Using GitHub-hosted runners within Azure VNET allows you to perform the following actions.

  • Privately connect a runner to resources inside an Azure VNET without opening internet ports, including on-premises resources accessible from the Azure VNET.
  • Restrict what GitHub-hosted runners can access or connect to with full control over outbound network policies.
  • Monitor network logs for GitHub-hosted runners and view all connectivity to and from a runner.

About network communication

To facilitate communication between GitHub networks and your VNET, a GitHub-hosted runner's network interface card (NIC) deploys into your Azure VNET.

A NIC enables an Azure virtual machine (VM) to communicate with internet, Azure, and on-premises resources. This way, all communication is kept private within the network boundaries, and networking policies applied to the VNET also apply to the runner. For more information on how to manage a network interface, see Change network interface settings in the Azure documentation.

Diagram of the network communication architecture between GitHub networks and your private networks. The diagram describes each step in connecting GitHub-hosted runners to an Azure VNET. Each step is numbered and the numbers correspond to the numbered descriptions of the step listed below the diagram.

  1. A GitHub Actions workflow is triggered.
  2. The GitHub Actions service creates a runner.
  3. The runner service deploys the GitHub-hosted runner's network interface card (NIC) into your Azure VNET.
  4. The runner agent picks up the workflow job. The GitHub Actions service queues the job.
  5. The runner sends logs back to the GitHub Actions service.
  6. The NIC accesses on-premise resources.

Using your VNET's network policies

Because the GitHub-hosted runner's NIC is deployed into your Azure VNET, networking policies applied to the VNET also apply to the runner.

For example, if your VNET is configured with an Azure ExpressRoute to provide access to on-premises resources (e.g. Artifactory) or connected to a VPN tunnel to provide access to other cloud-based resources, those access policies also apply to your runners. Additionally, any outbound rules applied to your VNET's network security group (NSG) also apply, giving you the ability to control outbound access for your runners.

If you have enabled any network logs monitoring for your VNET, you can also monitor network traffic for your runners.

Using GitHub-hosted runners with an Azure VNET

To use GitHub-hosted runners with Azure VNET, you will need to configure your Azure resources then create an Azure private network configuration in GitHub. For more information, see "Configuring private networking for GitHub-hosted runners."