Nota: Actualmente los ejecutores hospedados en GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.
Acerca del autoescalamiento
Puedes incrementar o decrementar la cantidad de ejecutores auto-hospedados en tu ambiente automáticamente como respuesta a los eventos de webhook que recibes con una etiqueta particular. Por ejemplo, puede crear una automatización que agregue un nuevo ejecutor autohospedado cada vez que reciba un evento de webhook de workflow_job con la actividad queued, que le notifica que hay un nuevo trabajo listo para su procesamiento. La carga útil de un webhook incluye datos de etiqueta, así que puedes identificar el tipo de ejecutor que está solicitando el job. Una vez finalizado el trabajo, puede crear una automatización que quite el ejecutor en respuesta a la actividad workflow_jobcompleted.
Soluciones de autoescalamiento recomendadas
GitHub recomienda tener a los socios de cerca con dos proyectos de código abierto que puedas utilizar para autoescalar tus ejectures. Una o ambas soluciones podrían ser adecuadas de acuerdo con tus necesidades.
Los siguientes repositorios tienen instrucciones detalladas para configurar estos autoescaladores:
- actions/actions-runner-controller: controlador de Kubernetes para ejecutores autohospedados de GitHub Actions.
- philips-labs/terraform-aws-github-runner: un módulo de Terraform para ejecutores escalables de GitHub Actions en Amazon Web Services.
Cada solución tiene especificaciones particulares que podría ser importante considerar:
| Características | actions-runner-controller | terraform-aws-github-runner |
|---|---|---|
| Tiempo de ejecución | Kubernetes | MV Linux y Windows |
| Nubes compatibles | Azure, Amazon Web Services, Google Cloud Platform, en las instalaciones | Amazon Web Services |
| Cuando los ejecutores pueden escalarse | Niveles de empresa, organización y repositorio. Por etiqueta y grupo de ejecutor. | Niveles de organización y repositorio. Por etiqueta y grupo de ejecutor. |
| Cómo pueden escalarse los ejecutores | Eventos de webhook, Programados, Basados en extracciones | Eventos de Webhook, Programados (únicamente ejecutores a nivel de organización) |
Utilizar ejecutores efímeros para autoescalar
GitHub recomienda implementar el autoescalamiento con ejecutores auto-hospedados efímeros; no se recomienda autoescalar con ejecutores auto-hospedados persistentes. En casos específicos, GitHub no puede garantizar que los jobs no se asignen a los ejecutores persistentes mientras están cerrados. Con los ejecutores efímeros, esto puede garantizarse, ya que GitHub solo asigna un job a un ejecutor.
Este acercamiento te permite administrar tus ejecutores como sistemas efímeros, ya que puedes utilizar la automatización para proporcionar un ambiente limpio para cada job. Esto ayuda a limitar la exposición de cualquier recurso sensible de los jobs anteriores y también ayuda a mitigar el riesgo de un ejecutor puesto en riesgo que esté recibiendo jobs nuevos.
Para agregar un ejecutor efímero a su entorno, incluya el parámetro --ephemeral al registrar el ejecutor mediante config.sh. Por ejemplo:
./config.sh --url https://github.com/octo-org --token example-token --ephemeralEl servicio de GitHub Actions entonces quitará el registro del ejecutor automáticamente después de que haya procesado un job. Entonces podrás crear tu propia automatización que elimine el ejecutor después de que se desregistró.
Nota: Si un trabajo se etiqueta para algún tipo de ejecutor, pero no hay ninguno disponible que coincida con esas características, el trabajo no fallará inmediatamente en el momento de ponerse en cola. En vez de esto, el job permanecerá en cola hasta que venza el tiempo límite de 24 horas.
Utilizar webhooks para autoescalar
Puede crear su propio entorno de escalado automático mediante cargas recibidas desde el webhook workflow_job. Este webhook está disponible en los niveles de repositorio, organización y empresa, y la carga de este evento contiene una clave action que corresponde a las fases del ciclo de vida de un trabajo de flujo de trabajo; por ejemplo, cuando los trabajos son queued, in_progress y completed. Entonces debes crear tu propia automatización de escalamiento en respuesta a estas cargas útiles de webhook.
- Para obtener más información sobre el webhook
workflow_job, consulte "Eventos y cargas útiles de un webhook". - Para aprender a trabajar con webhooks, consulte "Creación de webhooks".
Requisitos de autenticación
Puede registrar y eliminar los ejecutores autohospedados del repositorio y la organización mediante la API. Para autenticarte en la API, tu implementación de auto-escalamiento puede utilizar un token de acceso o una app de GitHub.
Tu token de acceso necesitará el siguiente alcance:
- En el caso de los repositorios privados, use un token de acceso con el alcance
repo. - En el caso de los repositorios públicos, use un token de acceso con el alcance
public_repo. - En el caso de las organizaciones, use un token de acceso con el alcance
admin:org.
Para autenticarte utilizando una App de GitHub, se le debe asignar los siguientes permisos:
- En el caso de los repositorios, asigne el permiso
administration. - En el caso de las organizaciones, asigne el permiso
organization_self_hosted_runners.
Puede registrar y eliminar ejecutores autohospedados empresariales mediante la API. Para autenticarte en la API, tu implementación de autoescalamiento puede utilizar un token de acceso.
El token de acceso requerirá el alcance manage_runners:enterprise.