CrestVPS

self hosted github runner

CI and build runners

Compilaciones que terminan antes de que cambies de pestaña.

Lo que implementaríamos

44,03 €/mes

62,90 €30% anual

Los minutos de CI alojados se miden, se ponen en cola y son lentos, y la curva de costes se vuelve fea en cuanto un equipo es productivo. Un par de instancias con núcleos dedicados y NVMe rápido superarán a la mayoría de los niveles alojados y costarán una cantidad fija cada mes sin importar cuántas veces hagas push. Se incluye virtualización anidada, por lo que Docker-in-Docker y suites de prueba basadas en KVM funcionan sin necesidad de soluciones alternativas.

Por qué esta configuración

TORQUE te da el número de núcleos, el NVMe Gen5 te da el rendimiento de artefactos y la virtualización anidada no cuesta nada. Registra los runners contra tu forge y elimina el plan alojado.

Lo que implementaríamos

PlanTORQUE T2
vCPU8 (dedicated)
RAM32 GB
Almacenamiento400 GB
ImagenUbuntu Server 24.04 LTS

Dimensionamiento

Dos núcleos dedicados y 4 GB por trabajo concurrente es el mínimo; los lenguajes compilados quieren 4 núcleos y 8 GB. Un nodo TORQUE de 32 núcleos ejecuta 8 trabajos pesados o unos 14 ligeros, no 32. El disco de scratch importa más que ambos: presupuesta 30-50 GB por trabajo concurrente en NVMe para capas de imagen, árboles de dependencias y salida de compilación. Añade un núcleo por nodo si los trabajos necesitan virtualización anidada. El tiempo de espera en cola, no la duración del trabajo, te indica cuándo añadir un nodo.

Virtualización anidada, y cuándo la necesitas

La mayoría de los CI funcionan bien en un contenedor. Tres casos necesitan un hipervisor real dentro del invitado: probar imágenes de VM y cloud-init, ejecutar emuladores Android o embebidos con aceleración KVM, y cualquier trabajo donde un pull request no confiable ejecute código que no debe alcanzar al runner. TORQUE expone SVM al invitado, por lo que KVM funciona dentro de tu VPS y el emulador corre a velocidad nativa en lugar de mediante emulación por software, lo que supone aproximadamente un orden de magnitud de diferencia en suites de prueba Android. El coste es un núcleo de sobrecarga para el hipervisor externo y un disco ligeramente más lento en el invitado interno. Presupuesta ambos.

La ruta de artefactos suele ser el cuello de botella

Perfila un pipeline lento y el paso de compilación rara vez es la barra más grande. Tirar de imágenes base, restaurar cachés, subir artefactos y empujar el resultado representan la mayor parte del tiempo de pared en builds típicos. Tres correcciones, en orden de retorno: mantén una caché de pull-through del registro en la misma VLAN privada para que las capas lleguen por red local en lugar de por internet público; pon el scratch en NVMe para que el desempaquetado de capas no esté limitado por búsqueda; y haz que la clave de caché sea precisa, para restaurar lo que necesitas en lugar de un archivo monolítico. Los núcleos Bergamo densos son baratos. Esperar en la red no lo es.

Qué sale mal

  • Apilar overlayfs sobre overlayfs para Docker-in-Docker. Los drivers overlay anidados son lentos y ocasionalmente corrompen capas. Usa un dispositivo de bloque dedicado dentro del trabajo, o ejecuta el builder sobre KVM anidado en su lugar.
  • Nunca hacer prune. Las imágenes colgantes, las cachés de build y los volúmenes obsoletos llenan el NVMe de scratch en semanas, y el primer síntoma es un build que falla en un paso que ha funcionado durante un año. Haz prune con un temporizador, no al fallar.
  • Dejar que la transferencia de caché exceda el tiempo de compilación. Una caché de dependencias de 3 GB extraída y subida por trabajo puede costar más que compilar desde cero. Mide ambas y mantén la caché en la misma VLAN privada que los runners.

Ajusta la máquina

  • Todo lo demásVirtualización anidada · Incluido
  • Planificación de CPUPinned physical cores · 9 €
  • Almacenamiento y cifradoZFS with hourly snapshots · 7 €