CrestVPS

self hosted github runner

Runner CI e di build

Build che finiscono prima che tu cambi scheda.

Cosa implementeremmo

44,03 €/mese

62,90 €30% annuale

I minuti CI ospitati sono misurati, in coda e lenti, e la curva dei costi diventa brutta nel momento in cui un team è produttivo. Un paio di istanze con core dedicati e NVMe veloce supereranno la maggior parte dei tier ospitati e costeranno un importo fisso ogni mese, indipendentemente dalla frequenza con cui fai push. La virtualizzazione annidata è inclusa, quindi i test suite Docker-in-Docker e KVM funzionano senza workaround.

Perché questa configurazione

TORQUE ti dà il numero di core, Gen5 NVMe ti dà la produttività degli artefatti e la virtualizzazione annidata non costa nulla. Registra i runner contro il tuo forge e elimina il piano ospitato.

Cosa implementeremmo

PlanTORQUE T2
vCPU8 (dedicated)
RAM32 GB
Storage400 GB
ImmagineUbuntu Server 24.04 LTS

Dimensionamento

Due core dedicati e 4 GB per job concorrente sono il minimo; i linguaggi compilati vogliono 4 core e 8 GB. Un nodo TORQUE a 32 core esegue quindi 8 job pesanti o circa 14 leggeri, non 32. Il disco di scratch conta più di entrambi: budget 30-50 GB per job concorrente su NVMe per layer di immagini, alberi delle dipendenze e output di build. Aggiungi un core per nodo se i job necessitano di virtualizzazione annidata. Il tempo di attesa in coda, non la durata del job, ti dice quando aggiungere un nodo.

Virtualizzazione annidata e quando ti serve

La maggior parte delle CI funziona bene in un contenitore. Tre casi richiedono un vero hypervisor all'interno del guest: testare immagini VM e cloud-init, eseguire emulatori Android o embedded con accelerazione KVM, e qualsiasi job in cui una pull request non fiducia esegua codice che non deve raggiungere il runner. TORQUE espone SVM al guest, quindi KVM funziona all'interno della tua VPS e l'emulatore gira a velocità nativa piuttosto che tramite emulazione software, che è circa un ordine di grandezza di differenza sulle suite di test Android. Il costo è un core di overhead per l'hypervisor esterno e un disco leggermente più lento nel guest interno. Metti in conto entrambi.

Il percorso degli artefatti è di solito il collo di bottiglia

Analizza una pipeline lenta e lo step di compilazione raramente è la barra più grande. Scaricare immagini base, ripristinare cache, caricare artefatti e spingere il risultato rappresentano la maggior parte del tempo totale in build tipiche. Tre correzioni, in ordine di ritorno: mantieni una cache pull-through del registro sulla stessa VLAN privata così i layer arrivano sulla rete locale piuttosto che su internet pubblico; metti lo scratch su NVMe così l'unpack dei layer non è limitato dalla ricerca; e rendi la chiave della cache precisa, così ripristini ciò che ti serve invece di un archivio monolitico. I core Bergamo densi sono economici. Aspettare sulla rete no.

Cosa va storto

  • Impilare overlayfs su overlayfs per Docker-in-Docker. I driver overlay annidati sono lenti e occasionalmente corrompono i layer. Usa un device a blocchi dedicato all'interno del job, o esegui il builder su KVM annidato.
  • Mai pulire. Immagini pendenti, cache di build e volumi obsoleti riempiono il disco NVMe di scratch in settimane, e il primo sintomo è una build che fallisce su uno step che ha funzionato per un anno. Pulisci con un timer, non al fallimento.
  • Lasciare che il trasferimento della cache superi il tempo di build. Una cache di dipendenze da 3 GB scaricata e caricata per job può costare più che compilare da zero. Misura entrambi e mantieni la cache sulla stessa VLAN privata dei runner.

Configura la macchina

  • Tutto il restoNested virtualisation (VMX/SVM) · Incluso
  • Scheduling CPUPinned physical cores · 9 €
  • Storage e crittografiaZFS with hourly snapshots · 7 €