Solución de problemas de configuración de redes privadas para ejecutores alojados en GitHub en su empresa
Habilitación de la creación de configuraciones de red para organizaciones en una empresa
De manera predeterminada, las organizaciones de una empresa no pueden crear configuraciones de red y solo heredan configuraciones de red de nivel empresarial. Los propietarios de empresas pueden establecer una directiva que permita a las organizaciones de la empresa crear configuraciones de red independientes de la empresa. Para más información, consulta Configurar redes privadas para los ejecutores hospedados en GitHub en su empresa.
Configuración de recursos de Azure antes de crear una configuración de red en GitHub
Asegúrese de que los recursos de Azure se han configurado antes de agregar una configuración de red en GitHub.
Regiones compatibles
El GitHub Actions servicio admite un subconjunto de todas las regiones que proporciona Azure. Para facilitar la comunicación entre el servicio GitHub Actions y tu subred, esta debe encontrarse en una de las regiones admitidas.
Nota:
Si usa residencia de datos en GHE.com, las regiones admitidas son diferentes. Consulta Detalles de red para GHE.com.
Las regiones siguientes se admiten en GitHub.com.
AustraliaEastBrazilSouthCanadaCentralCanadaEastCentralUsEastAsiaEastUsEastUs2FranceCentralGermanyWestCentralJapanWestKoreaCentralNorthCentralUsNorthEuropeNorwayEastSouthCentralUsSoutheastAsiaSouthIndiaSwedenCentralSwitzerlandNorthUkSouthUkWestWestUsWestUs2WestUs3
Las redes privadas de Azure admiten ejecutores de GPU en las siguientes regiones.
EastUsNorthCentralUsSouthCentralUsWestUs
Las redes privadas de Azure admiten ejecutores de ARM64 en las siguientes regiones.
CentralUsEastUsEastUs2NorthCentralUsSouthCentralUsWestUsWestUs2WestUs3
Pronto iniciaremos un proceso para solicitar soporte técnico para las nuevas regiones. También puede usar el emparejamiento global de redes virtuales para conectar redes virtuales en distintas regiones de Azure. Para obtener más información, consulte Emparejamiento de redes virtuales en la documentación de Azure.
El ejecutor no pudo conectarse a Internet
Los ejecutores alojados GitHub
en deben poder establecer conexiones salientes con GitHub, así como con otras URL necesarias para GitHub Actions.
Si GitHub Actions no puede comunicarse con los ejecutores, el grupo nunca podrá ponerlos en línea y, por lo tanto, no se recogerá ningún trabajo. En este caso, el grupo tendrá el siguiente código de error.
VNetInjectionFailedToConnectToInternet
Para corregirlo, asegúrate de que has configurado los recursos de Azure según los procedimientos que se indican en "Configuración de los recursos de Azure".
El ámbito de implementación está bloqueado
Puede colocar bloqueos en la suscripción o el grupo de recursos de Azure, lo que puede impedir la creación o eliminación de la NIC.
Los bloqueos que impiden la creación de NIC no pueden recoger trabajos, mientras que los bloqueos que impiden la eliminación de NIC agotan el espacio de direcciones de subred (al continuar con la creación de NIC) o tienen largos tiempos de cola para asignar (QTA) a medida que el servicio reintenta las excepciones de implementación.
En este caso, el pool tendrá el siguiente código de error.
RunnerDeploymentScopeLocked
Para corregirlo, elimine el bloqueo o cambie la subred que está usando a una sin bloqueo.
Implementación bloqueada por directiva
Puede crear directivas en su grupo de administración, suscripción, grupo de recursos o recursos individuales. La directiva más común es requerir que un recurso tenga determinadas etiquetas o que tenga un nombre específico.
La directiva impedirá la creación de NIC, lo que significa que el conjunto no ejecutará trabajos, ya que ninguna máquina virtual puede estar operativa.
En este caso, el pool tendrá el siguiente código de error.
RunnerDeploymentBlockedByPolicy
Para corregir esto, elimine la directiva o cambie la subred que está usando a una sin directiva.
La subred está completa
Las subredes tienen una cantidad limitada de direcciones IP que se van a distribuir. Cada ejecutor consume una dirección IP. Si el servicio intenta escalar verticalmente más allá del número máximo de ejecutores configurado, se producirán errores de implementación.
Esto afecta a la capacidad del grupo de agregar ejecutores adicionales. Si la profundidad de la cola es lo suficientemente alta, puede experimentar un aumento de los tiempos de cola para asignar (QTA). Los trabajos se seguirán procesando, pero no con el nivel de simultaneidad que pueda esperar.
En este caso, el pool tendrá el siguiente código de error.
VNetInjectionSubnetIsFull
Para corregir esto, aumente el tamaño de la subred que usa o reduzca el número máximo de ejecutores del grupo para que coincidan con el tamaño de la subred.
No se puede eliminar la subred
En algunos casos, no se puede eliminar una subred porque tiene aplicado un vínculo de asociación de servicio (SAL). Para más información, consulta Configuración de redes privadas para los ejecutores hospedados en GitHub en su organización.
Si necesitas identificar el recurso de configuración de red asociado a la subred, puedes ejecutar el siguiente comando curl.
Para obtener un token de Azure Entra, consulta la documentación de Azure. Usa el mismo valor api-version que usaste para crear el 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}"
Reglas de NSG o de firewall incorrectas
Los procedimientos de "Configuración de los recursos de Azure" enumeran las aperturas necesarias. Sin embargo, es posible que tenga redes de producción complejas con varios servidores proxy o firewalls de bajada.
Si los ejecutores no pueden ponerse en línea, no se recogerá ningún trabajo. Es posible que el proceso de configuración implique configurar la aplicación del ejecutor y comunicarse con el servicio GitHub Actions para indicar que está listo, así como descargar e instalar herramientas contra el uso indebido. Si se produce un error en cualquiera de estos procesos, el ejecutor no puede recoger ningún trabajo.
Si experimenta estos problemas, intente configurar una máquina virtual en la misma subred que está utilizando para la red privada con los ejecutores alojados en GitHub. Sin embargo, si cuenta con un vínculo de asociación de servicio (SAL), esto no será posible.
Si cuenta con un SAL, pruebe a configurar una subred similar en la red virtual y coloque una máquina virtual en esa red. A continuación, intente registrar un ejecutor autohospedado en él.
Error de carga de solicitud HTTP al configurar recursos de Azure
Al ejecutar el comando para configurar los recursos de Azure, asegúrese de que usa la versión de API correcta y la propiedad businessId. Si usa una propiedad diferente, el comando puede devolver el siguiente error.
(HttpRequestPayloadAPISpecValidationFailed) HTTP request payload failed validation against API specification with one or more errors. Please see details for more information.
Si experimenta este error, puede ver más información ejecutando el comando mediante la marca ---debug.
Configuración de red configurada en el nivel incorrecto
Si la configuración de red se configuró mediante el databaseId de una organización en lugar de una databaseIdempresarial, se producirá un error. El mensaje de error indicará que no se puede establecer una red privada con el identificador de recurso proporcionado porque ya está asociado a otra empresa u organización. Para resolverlo, elimine la configuración de red existente y vuelva a crearla mediante la empresa databaseId.
La red de conmutación por error no redirige el tráfico
Nota:
La conmutación por error de VNET se encuentra en versión preliminar pública y está sujeta a cambios. El cambio entre las redes principal y de respaldo es un proceso gradual. Durante la transición, es posible que los ejecutores se ejecuten en ambas redes simultáneamente. En función de las pruebas, la transición completa tarda aproximadamente 15 minutos. Asegúrese de que ambas subredes permanecen accesibles durante este período.
Si al habilitar la red de conmutación por error no parece que se redirija el tráfico de los ejecutores, compruebe lo siguiente:
- Asegúrese de que los recursos de Azure de la subred de conmutación por error (VNET/subred, NSG/firewall, configuración de red) estén correctamente configurados. Siga los mismos procedimientos de configuración de los recursos de Azure que se usan para la subred principal.
- Confirme que la red de conmutación por error se agregó a la configuración de red correcta y que la configuración está asociada al grupo de ejecutores adecuado.
No se puede acceder a la subred de conmutación por error
Si los ejecutores no se pueden conectar después de habilitar la red de conmutación por error, es probable que el problema se produzca con los recursos de Azure configurados para la subred de conmutación por error.
- Asegúrese de que la subred de conmutación por error tenga aplicadas las reglas de NSG o firewall correctas que coincidan con los requisitos enumerados en los procedimientos Configurar redes privadas para los ejecutores hospedados en GitHub en su empresa.
- Verifique que la subred de conmutación por error tenga suficiente espacio de direcciones IP para la concurrencia prevista de ejecutores.
No se puede volver al nodo principal después de la conmutación por error iniciada por GitHub
- Vaya a la configuración de red en los ajustes de Redes de proceso alojadas.
- Haga clic en el icono de edición situado junto a la configuración de red. A continuación, haga clic en Editar configuración.
- Haga clic en Desactivar VNET de conmutación por error para devolver el tráfico de los ejecutores a la subred principal.
Si no puede desactivar la conmutación por error, asegúrese de que los recursos de Azure de la subred principal estén en buen estado y sean accesibles. Compruebe que no haya interrupciones en curso en la región de Azure de la subred principal.