Solucionando problemas de configuração de redes privadas para executores hospedados pela GitHub em sua empresa
Habilitar a criação de configurações de rede para organizações em uma empresa
Por padrão, as organizações em uma empresa não podem criar novas configurações de rede e apenas herdar configurações de rede de nível empresarial. Os proprietários da empresa podem definir uma política que permita que as organizações na empresa criem configurações de rede independentes da empresa. Para saber mais, confira Configurando a rede privada para executores hospedados por GitHub em sua empresa.
Configurando recursos do Azure antes de criar uma configuração de rede no GitHub
Verifique se os recursos do Azure foram configurados antes de adicionar uma configuração de GitHubrede.
Regiões com suporte
O GitHub Actions serviço dá suporte a um subconjunto de todas as regiões fornecidas pelo Azure. Para facilitar a comunicação entre o GitHub Actions serviço e sua sub-rede, sua sub-rede deve estar em uma das regiões com suporte.
Observação
Se você usar residência de dados em GHE.com, as regiões com suporte serão diferentes. Confira Detalhes de rede do GHE.com.
Há suporte para as seguintes regiões GitHub.com.
AustraliaEastBrazilSouthCanadaCentralCanadaEastCentralUsEastAsiaEastUsEastUs2FranceCentralGermanyWestCentralJapanWestKoreaCentralNorthCentralUsNorthEuropeNorwayEastSouthCentralUsSoutheastAsiaSouthIndiaSwedenCentralSwitzerlandNorthUkSouthUkWestWestUsWestUs2WestUs3
A rede privada do Azure oferece suporte a executores de GPU nas seguintes regiões.
EastUsNorthCentralUsSouthCentralUsWestUs
A rede privada do Azure oferece suporte a executores de arm64 nas regiões a seguir.
CentralUsEastUsEastUs2NorthCentralUsSouthCentralUsWestUsWestUs2WestUs3
Iniciaremos um processo para solicitar suporte para novas regiões em breve. Você também pode usar emparelhamento de rede virtual global para conectar redes virtuais em diferentes regiões do Azure. Para obter mais informações, consulte Emparelhamento de Rede Virtual na documentação do Azure.
O executor não conseguiu se conectar à internet
Os executores hospedados em GitHub
precisam ser capazes de fazer conexões de saída para GitHub, bem como para outros URLs necessários para GitHub Actions.
Se GitHub Actions não puder se comunicar com os executores, o pool nunca será capaz de colocar os executores online e, portanto, nenhum trabalho será escolhido. Nesse caso, o pool terá o seguinte código de erro.
VNetInjectionFailedToConnectToInternet
Para corrigir isso, verifique se você configurou seus recursos do Azure de acordo com os procedimentos "Configurar seus recursos do Azure".
O escopo de implantação está bloqueado
Você pode colocar bloqueios na assinatura do Azure ou no grupo de recursos, o que pode impedir a criação ou exclusão de NIC.
Os bloqueios que impedem a criação de NIC não conseguem captar trabalhos, enquanto os bloqueios que impedem a exclusão de NIC esgotam o espaço de endereço da sub-rede (continuando a criar NICs) ou têm longos tempos de fila para atribuição (QTA) à medida que o serviço repete exceções de implantação.
Nesse caso, o pool terá o seguinte código de erro.
RunnerDeploymentScopeLocked
Para consertar isso, remova o bloqueio ou altere a sub-rede que você está usando para uma sem bloqueio.
Implantação bloqueada pela política
Você pode criar políticas em seu grupo de gerenciamento, assinatura, grupo de recursos ou recursos individuais. A política mais comum é exigir que um recurso tenha determinadas marcas ou um nome específico.
A política impedirá a criação de NICs, o que significa que o pool não assumirá tarefas, já que não haverá VMs online.
Nesse caso, o pool terá o seguinte código de erro.
RunnerDeploymentBlockedByPolicy
Para corrigir isso, remova a política ou altere a sub-rede que você está usando para uma sem uma política.
A subrede está cheia
As sub-redes têm uma quantidade limitada de endereços IP para distribuir. Cada executor consome um endereço IP. Se o serviço tentar escalar verticalmente além da configuração de contagem máxima de executores, ele encontrará erros de implantação.
Isso afeta a capacidade do pool de adicionar executores adicionais. Se a profundidade da fila for alta o suficiente, você pode enfrentar tempos de fila para atribuição (QTA) aumentados. Os trabalhos ainda serão processados, mas não em um nível de simultaneidade que você possa esperar.
Nesse caso, o pool terá o seguinte código de erro.
VNetInjectionSubnetIsFull
Para corrigir isso, aumente o tamanho da subrede que você está usando ou reduza o número máximo de runners do pool para corresponder ao tamanho da subrede.
Não é possível excluir a sub-rede
Em alguns casos, uma sub-rede não pode ser excluída porque tem um SAL (Service Association Link) aplicado a ela. Para saber mais, confira Configurando rede privada para executores hospedados no GitHub na sua organização.
Se você precisar identificar o recurso de configurações de rede associado à sub-rede, poderá executar o comando curl a seguir.
Para obter um token do Azure Entra, consulte a documentação do Azure. Use o mesmo api-version usado para criar o recurso.
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}"
Regras de firewall ou NSG incorretas
Os procedimentos "Configurando seus recursos do Azure" listam as aberturas necessárias. No entanto, você pode ter redes de produção complexas com vários proxies ou firewalls downstream.
Se os executores não estiverem online, nenhum trabalho será pego. Seu processo de instalação pode envolver a configuração do aplicativo executor e a comunicação de volta ao serviço GitHub Actions para indicar que está pronto, bem como obter e instalar ferramentas antiabuso. Se qualquer um desses processos falhar, o executor não poderá pegar nenhum trabalho.
Se você estiver enfrentando esses problemas, tente configurar uma máquina virtual na mesma sub-rede que você está usando para rede privada com executores hospedados em GitHub. No entanto, se você tiver um link de associação de serviço (SAL) em vigor, isso não será possível.
Se você tiver um SAL em vigor, tente configurar uma sub-rede semelhante na rede virtual e coloque uma máquina virtual nessa rede. Em seguida, tente registrar um executor auto-hospedado nela.
Falha no payload de solicitação HTTP ao configurar recursos do Azure
Ao executar o comando para configurar os recursos do Azure, verifique se você está usando a versão correta da API e a propriedade businessId. Se você estiver usando uma propriedade diferente, seu comando pode retornar o seguinte erro.
(HttpRequestPayloadAPISpecValidationFailed) HTTP request payload failed validation against API specification with one or more errors. Please see details for more information.
Se ocorrer esse erro, você poderá ver mais informações executando o comando usando o sinalizador ---debug.
Configurações de rede definidas no nível errado
Se as configurações de rede foram definidas com a databaseId de uma organização em vez de a databaseId de uma empresa, ocorrerá um erro. A mensagem de erro indicará que uma rede privada não pode ser estabelecida com a ID do recurso fornecida porque ela já está associada a uma empresa ou organização diferente. Para resolver isso, exclua as configurações de rede existentes e recrie-as usando a databaseId da empresa.
A rede de failover não está redirecionando o tráfego
Observação
O failover da VNET está em versão prévia pública e está sujeito a alterações. Alternar entre as redes primárias e de failover é um processo gradual. Durante a transição, os executores podem estar operando em ambas as redes simultaneamente. Com base no teste, a transição completa leva aproximadamente 15 minutos. Verifique se ambas as sub-redes permanecem acessíveis durante esse período.
Se habilitar a rede de failover não parecer redirecionar o tráfego do executor, verifique o seguinte:
- Verifique se os recursos do Azure da sub-rede de failover (rede virtual/sub-rede, NSG/firewall, configurações de rede) estão configurados corretamente. Siga os mesmos procedimentos "Configurando seus recursos do Azure" usados para sua sub-rede primária.
- Confirme se a rede de contingência foi adicionada à configuração de rede correta e se a configuração está associada ao grupo de executores apropriado.
Sub-rede de failover não acessível
Se os executores não puderem se conectar após habilitar a rede de contingência, o problema provavelmente estará nos recursos do Azure configurados para a sub-rede de contingência.
- Verifique se a sub-rede de failover tem as regras corretas de NSG ou de firewall aplicadas, de acordo com os requisitos listados nos procedimentos Configurando a rede privada para executores hospedados por GitHub em sua empresa.
- Verifique se a sub-rede de failover possui espaço de endereço IP suficiente para permitir a concorrência esperada do executor.
Não é possível alternar de volta para o primário após o failover iniciado pelo GitHub
- Acesse as suas configurações de rede em Rede de Computação Hospedada.
- Clique no ícone de edição ao lado da configuração de rede. Em seguida, clique em Editar configuração.
- Clique em Desabilitar VNET de failover para retornar o tráfego do executor à sub-rede primária.
Se você não conseguir desabilitar o failover, verifique se os recursos da sub-rede primária do Azure estão íntegros e acessíveis. Verifique se não há interrupções contínuas na região do Azure da sub-rede primária.