Sabias que podes tener hasta 10000 ejecutores propios en Github Actions?

Introducción

¿Sabías que podés tener hasta 10.000 runners auto-hospedados en Github? Sí, leíste bien, eso significa que podés controlar tus costos, cómo organizás y gestionás tu infraestructura de CI. Por defecto, en este momento, los límites de uso de GitHub son bastante altos para los runners auto-hospedados. Podés leer más aquí.

Esto puede cambiar, así que revisá su documentación para una versión actualizada, pero por ahora los límites son:

• Tiempo de ejecución del trabajo: Cada trabajo en un workflow puede ejecutarse hasta 5 días. Si se alcanza este límite, el trabajo se cancela y falla.
• Tiempo de ejecución del workflow: Cada ejecución de un workflow está limitada a 35 días. Si se alcanza este límite, la ejecución del workflow se cancela. Este período incluye la duración de la ejecución, el tiempo de espera y la aprobación.
• Tiempo en la cola del trabajo: Cada trabajo para runners auto-hospedados que haya estado en cola por al menos 24 horas se cancelará. El tiempo en cola real puede llegar hasta 48 horas antes de que ocurra la cancelación.
• Solicitudes a la API: Podés ejecutar hasta 1.000 solicitudes a la API de GitHub en una hora en todas las acciones dentro de un repositorio. Si se exceden las solicitudes, las llamadas adicionales a la API fallarán, lo que podría causar que los trabajos fallen.
• Matriz de trabajos: Una matriz de trabajos puede generar un máximo de 256 trabajos por ejecución de workflow. Este límite se aplica tanto a los runners auto-hospedados como a los runners hospedados por GitHub.
• Cola de ejecución de workflows: No más de 500 ejecuciones de workflow pueden estar en cola en un intervalo de 10 segundos por repositorio. Si se alcanza este límite, la ejecución del workflow se termina y falla.
• Registro de runners auto-hospedados: Podés tener un máximo de 10.000 runners auto-hospedados en un grupo de runners. Si se alcanza este límite, no será posible agregar un nuevo runner.

Podés agregar un runner auto-hospedado a un repositorio, una organización o una empresa.

¿Por qué necesito runners auto-hospedados?

Imaginá que necesitás construir y ejecutar software en Linux ARM64. Todavía no hay runners hospedados por GitHub para ese sistema operativo y arquitectura.

Además, obtenés control total de tu runner. Esto puede ser complicado en repositorios públicos donde alguien podría enviar un Pull Request para filtrar información sobre tu infraestructura o ejecutar un paquete peligroso, etc. Si vas a usar esto en público, deberías dedicar tiempo a endurecer la configuración para evitar malos actores. Sin embargo, hay varias alternativas que pueden funcionar bien.

Algunos módulos de terraform interesantes y alternativas:

• https://philips-labs.github.io/terraform-aws-github-runner
• https://github.com/cloudandthings/terraform-aws-github-runners

¿Cómo puedo comenzar con los runners auto-hospedados?

Es bastante simple. Si solo lo vas a usar desde un repositorio específico, podés agregarlo desde la configuración del repositorio. Aquí tenés un ejemplo: andá a tu repositorio, luego a “actions”, luego a “runners”, y hacé clic en el botón verde para agregar un nuevo runner. Debería verse algo así 👇.

El siguiente paso sería configurarlo en tu nodo. Esto, por supuesto, no es la forma más confiable de configurar tus runners, especialmente cuando necesitás considerar el auto-escalado, el escalado a cero, o runners efímeros. Sin embargo, para probar o comenzar es suficiente.

Si todo se hizo correctamente, deberías ver tu nodo listado allí:

Para eliminar el nodo, simplemente ejecutá el script nuevamente como se muestra en la imagen.

Y eso es todo. Recordá ser muy consciente de la seguridad y restringir fuertemente las acciones que se pueden realizar en tu repositorio si es un repositorio público.

Errata

Si encontrás algún error o tenés alguna sugerencia, mandame un mensaje para que se pueda corregir.

También podés revisar el código fuente y los cambios en los sources aquí