Hosting per runner CI
Risposta
Runner CI self-hosted eseguono le pipeline di build su server che controlli, anziché sul pool condiviso del provider. Una VPS Incognito VPS VECTOR a 14 $ al mese supera in genere un runner ospitato, eliminando del tutto la fatturazione al minuto e i tempi di attesa in coda.
| Scenario | Minimo |
|---|---|
| Progetto piccolo | 2 vCPU, 4 GB di RAM |
| Monorepo tipica | 6 vCPU, 16 GB di RAM |
| Compilazione pesante (Rust, C++) | 16 vCPU, 64 GB di RAM |
| Cache dei layer Docker | 140+ GB NVMe |
Spesso è decisiva l'aritmetica
I minuti di CI ospitata sembrano economici finché non li conti. Un team che esegue qualche centinaio di build al mese su runner ospitati a 2 core spende di solito più di una VPS dedicata a 6 core, ottenendo anche build più lente perché i runner ospitati sono macchine modeste e contendono risorse.
L'altro risparmio è di tempo, non di denaro. Con un runner self-hosted non c'è coda: il lavoro parte quando fai push. Su un pool ospitato affollato l'attesa di diversi minuti per un runner è normale, e colpisce ogni sviluppatore e ogni push.
La cache è la vera fonte di accelerazione
Un NVMe locale persistente cambia l'economia della CI più del numero di core. I layer Docker, i registry Cargo, node_modules, le cache Gradle e ccache sopravvivono tra un'esecuzione e l'altra su un runner self-hosted, mentre un runner ospitato parte pulito e riscarica tutto.
Per un grande progetto Rust o C++ ciò si traduce spesso in una riduzione da cinque a dieci volte del tempo di build a cronometro, ed è del tutto gratuito.
Isolamento, perché i runner eseguono codice arbitrario
Un runner self-hosted esegue tutto ciò che è nella pipeline, e per un repository pubblico significa ciò che un contributore inserisce in una pull request. Non collegare mai un runner self-hosted a un repository pubblico senza esecuzione effimera e isolata.
Usa runner effimeri in contenitori o VM a breve durata, non concedere al runner credenziali che non gli servono e mettilo su un server senza altro. Una macchina da 14 $ per progetto è una assicurazione economica contro una pipeline compromessa che raggiunge il resto dell'infrastruttura.
Domande frequenti
01 Quale piano per un runner CI?
VECTOR (4 vCPU, 8 GB) per un progetto tipico; BASTION (6 vCPU, 16 GB) per una monorepo o compilazione pesante. La cache NVMe persistente conta più del numero di core per la maggior parte delle pipeline.
02 Funziona con GitHub Actions?
Sì. Registra la macchina come runner self-hosted e punta a essa con runs-on. GitLab, Forgejo, Woodpecker e Drone funzionano allo stesso modo.
03 Un runner self-hosted è sicuro per i repo pubblici?
Non senza isolamento effimero. Una pull request può eseguire codice arbitrario sul runner. Usa contenitori effimeri o VM usa-e-getta e non concedere mai credenziali che la pipeline non richiede.
04 Quanto più veloce?
In genere da due a quattro volte sul calcolo puro, e da cinque a dieci volte sulle pipeline con pesante uso di cache, perché i layer Docker e le cache delle dipendenze persistono tra le esecuzioni invece di essere riscaricati.
Correlati