Autoescalar con ejecutores auto-hospedados

Puedes escalar tus ejecutores auto-hospedados automáticamente en respuesta a eventos de webhook.

En este artículo

Note

Actualmente los ejecutores hospedados por 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, puedes crear una automatización que agregue un nuevo ejecutor auto-hospedado cada vez que recibas un evento de webhook workflow_job con la actividad queued, que 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 escalado automático admitidas

El proyecto actions/actions-runner-controller (ARC) es un escalador automático de ejecutor basado en Kubernetes. GitHub recomienda ARC si el equipo que implementa tiene conocimientos y experiencia a nivel de experto en Kubernetes.

Para más información, consulta Acerca de Actions Runner Controller y Acerca de la compatibilidad con Actions Runner Controller.

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.

Warning

Los archivos de registro de aplicaciones del ejecutor para ejecutores efímeros deben reenviarse a una solución de almacenamiento de registros externa para solucionar problemas y diagnósticos. Aunque no es necesario que se implementen ejecutores efímeros, GitHub recomienda garantizar que los registros del ejecutor se reenvíen y conserven externamente antes de implementar una solución de escalado automático de ejecutores efímeros en un entorno de producción. Para más información, consulta Supervisión y solución de problemas de ejecutores autohospedados.

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 --ephemeral

El 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ó.

Note

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.

Como alternativa, puedes crear ejecutores efímeros y Just-In-Time mediante la API REST. Para más información, consulta Puntos de conexión de API de REST para ejecutores autohospedados.

Controlar la actualizaciones de software ejecutor en ejecutores auto-hospedados

Predeterminadamente, los ejecutores auto-hospedados realizan una actualización de software cuando una versión nueva del software ejecutor esté disponible. Si usas ejecutores efímeros en contenedores, esto podría ocasionar que existieran actualizaciones de software repetidas cuando se lance una versión nueva del ejecutor. El apagar las actualizaciones automáticas te permite actualizar la versión del ejecutor directamente en la imagen del contenedor en tu propia programación de tiempos.

Para desactivar las actualizaciones automáticas de software e instalar las actualizaciones de software usted mismo, especifique la marca --disableupdate al registrar el ejecutor mediante config.sh. Por ejemplo:

./config.sh --url https://github.com/YOUR-ORGANIZATION --token EXAMPLE-TOKEN --disableupdate

Si inhabilitas las actualizaciones automáticas, aún debes actualizar tu versión de ejecutor con frecuencia. La nueva funcionalidad de GitHub Actions requiere cambios tanto en el servicio de GitHub Actions como en el software del ejecutor. El ejecutor podría no ser capaz procesar correctamente los jobs que toman ventaja de las características nuevas en GitHub Actions sin una actualización de sfotware.

Si inhabilitas las actualizaciones automáticas, necesitarás actualizar la versión de tu ejecutor en los siguientes 30 días después de que una versión nueva esté disponible. Es posible que desee suscribirse a las notificaciones para las versiones del actions/runner repositorio. Para más información, consulta Configuración de notificaciones.

Para saber cómo instalar la versión más reciente del ejecutor, consulte las instrucciones de instalación de la versión más reciente.

Warning

Las actualizaciones publicadas para el software, incluidas las versiones principales, secundarias o de revisión, se consideran una actualización disponible. Si no ejecutas una actualización de software en los 30 días posteriores, el servicio de GitHub Actions no pondrá los trabajos en cola para el ejecutor. Adicionalmente, si se requiere una actualización de seguridad crítica, el servicio de las GitHub Actions no pondrá jobs en cola para tu ejecutor sino hasta que este se actualice.

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.

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.