GitHub ha anunciado oficialmente la disponibilidad general de las imágenes personalizadas para los runners hospedados en GitHub Actions, dejando atrás la fase de vista previa pública iniciada meses atrás.
Aunque a simple vista puede parecer una mejora incremental, en realidad estamos ante un cambio importante en cómo los equipos de ingeniería gestionan la ejecución de pipelines de CI/CD a escala.
Este nuevo sistema responde a un problema muy conocido en equipos DevOps: el coste acumulado de preparar entornos de ejecución desde cero en cada workflow.
El problema que GitHub intenta resolver
En los runners estándar de GitHub Actions, cada ejecución de workflow comienza en un entorno limpio.
Eso significa que, en cada job:
- Se instalan runtimes como Node.js o Python
- Se descargan SDKs y dependencias
- Se configuran certificados internos
- Se instalan binarios y herramientas propias del equipo
Y todo esto ocurre, una y otra vez. En los entornos más pequeños esto es aceptable. Pero en sistemas de CI a gran escala, este modelo empieza a convertirse en un problema serio de rendimiento y coste.
La solución: imágenes personalizadas de runners
La propuesta de GitHub es simple en concepto pero potente en impacto: “En lugar de configurar el entorno en cada ejecución, se construye una imagen preconfigurada una sola vez”.
Esto permite que los workflows:
- Eviten reinstalar dependencias en cada ejecución
- Reduzcan tiempos de arranque de los jobs
- Usen entornos consistentes y controlados
- Mejoren la estabilidad de los pipelines
El resultado es un modelo más cercano a “infraestructura como artefacto”.
¿Cómo funciona el sistema de custom images?
El flujo se basa en tres pasos principales:
1. Crear un runner de generación de imágenes
Se configura un entorno específico encargado de construir la imagen base.
2. Usar el keyword snapshot en un workflow
Cada ejecución con snapshot genera una nueva imagen del entorno.
3. Crear runners basados en esa imagen
Los runners posteriores utilizan esa imagen preconstruida en lugar de empezar desde cero.
Versionado automático de imágenes
Uno de los aspectos más interesantes es el sistema de versionado:
- Cada ejecución exitosa genera una nueva versión de imagen
- GitHub incrementa automáticamente la versión menor
- Se pueden fijar versiones específicas si se necesita control total
- También es posible usar la versión más reciente automáticamente
Esto permite dos modelos de uso:
- Entornos dinámicos que siempre se actualizan
- Entornos estables fijados para producción crítica
Actualizaciones y mantenimiento: el nuevo desafío
GitHub recomienda regenerar imágenes al menos una vez por semana.
Esto tiene ventajas claras:
- Aplicación de parches de seguridad
- Actualización de dependencias
- Reducción de drift entre entornos
Pero también introduce un nuevo concepto importante, las imágenes de runners se convierten en un artefacto más del sistema, igual de importante que el propio código.
Esto implica que ahora necesitan:
- Versionado
- Auditoría
- Control de cambios
- Políticas de retención
En otras palabras: los pipelines también tienen infraestructura propia que gestionar.
Limitaciones importantes del sistema
Aunque es una mejora significativa, esta funcionalidad no es un sistema de imágenes libre.
Algunas restricciones clave:
- Solo disponible en planes GitHub Team y Enterprise Cloud
- Requiere runners de mayor capacidad
- No permite importar imágenes arbitrarias externas (como AMIs libres o imágenes de GCP personalizadas)
- Todo el sistema permanece dentro del ecosistema de GitHub
Esto significa que no es una solución universal de imágenes de máquinas virtuales, sino una solución controlada dentro de Actions.
Comparación con otros sistemas CI/CD
GitLab CI
GitLab permite algo más flexible:
- Uso directo de imágenes Docker desde registros públicos o privados
- Ejecución en contenedores sin pasos adicionales
- Control completo del ciclo de vida de la imagen
- Mayor responsabilidad en la gestión del entorno por parte del equipo
En este sentido, GitLab ofrece más libertad, pero también más carga operativa.
CircleCI
CircleCI combina dos modelos:
- Ejecutores basados en contenedores (Docker)
- Máquinas completas con entornos personalizados
Sin embargo:
- Las imágenes VM personalizadas tipo AMI no están tan integradas en su oferta cloud
- Muchos equipos que necesitan ese nivel de control terminan usando runners autoalojados
El enfoque de GitHub: equilibrio entre control y simplicidad
La propuesta de GitHub se sitúa en un punto intermedio:
- Más control que runners estándar
- Menos complejidad que gestionar self-hosted runners
- Integración nativa dentro de Actions
- Menos flexibilidad que soluciones totalmente abiertas
El trade-off es claro, menos flexibilidad a cambio de menos carga operativa.
Implicaciones para equipos de ingeniería
Este cambio introduce una evolución importante en cómo se piensa CI/CD:
1. Los runners dejan de ser efímeros simples
Ahora son entornos versionados.
2. La infraestructura de CI se vuelve un activo gestionado
Las imágenes deben mantenerse igual que el código.
3. El rendimiento mejora, pero la gobernanza aumenta
Más velocidad implica más responsabilidad operativa.
4. DevOps se acerca más a “image engineering”
Construir, versionar y auditar entornos será parte del flujo estándar.
Conclusión
Las imágenes personalizadas de GitHub Actions no son solo una mejora de rendimiento. Son un cambio conceptual en cómo se construye la infraestructura de CI.
El pipeline deja de ser solo un conjunto de pasos y pasa a depender de un entorno preconstruido, versionado y gestionado como un artefacto crítico.
Para equipos pequeños puede parecer un detalle técnico. Para equipos grandes, puede convertirse en una pieza clave para reducir tiempos de build, estandarizar entornos y escalar CI sin fricción.