CrestVPS

self hosted github runner

CI- en buildrunners

Builds die klaar zijn voordat je van tabblad wisselt.

Wat wij zouden implementeren

€ 44,03/mnd

€ 62,9030% jaarlijks

Gehoste CI-minuten zijn gemeten, in de wachtrij en traag, en de kostencurve wordt lelijk zodra een team productief is. Een paar dedicated-core-instanties met snelle NVMe verslaan de meeste gehoste tiers en kosten elke maand een vast bedrag, ongeacht hoe vaak je pusht. Geneste virtualisatie is inbegrepen, dus Docker-in-Docker- en KVM-gebaseerde testsuites werken zonder workaround.

Waarom deze configuratie

TORQUE geeft je het aantal cores, Gen5 NVMe geeft je de artifact-doorvoer, en geneste virtualisatie kost niets. Registreer de runners tegen je forge en verwijder het gehoste plan.

Wat wij zouden implementeren

PlanTORQUE T2
vCPU8 (dedicated)
RAM32 GB
Opslag400 GB
ImageUbuntu Server 24.04 LTS

Sizing

Twee dedicated cores en 4 GB per gelijktijdige job is het minimum; compiled talen willen 4 cores en 8 GB. Een 32-core TORQUE-node draait dus 8 zware jobs of ongeveer 14 lichte, niet 32. Scratch-schijf belangrijker dan beide — budget 30-50 GB per gelijktijdige job op NVMe voor image-lagen, dependency-bomen en build-output. Voeg een core per node toe als jobs geneste virtualisatie nodig hebben. Wachttijd in de wachtrij, niet jobduur, vertelt je wanneer je een node moet toevoegen.

Geneste virtualisatie, en wanneer je het nodig hebt

De meeste CI draait prima in een container. Drie gevallen hebben een echte hypervisor in de guest nodig: het testen van VM-images en cloud-init, het draaien van Android- of embedded-emulators met KVM-versnelling, en elke job waarbij een niet-vertrouwde pull request code uitvoert die de runner niet mag bereiken. TORQUE stelt SVM bloot aan de guest, dus KVM werkt in je VPS en de emulator draait op native snelheid in plaats van via software-emulatie, wat ongeveer een orde van grootte verschil is op Android-testsuites. De kosten zijn één core overhead voor de buitenste hypervisor en iets tragere schijf in de innerlijke guest. Budget voor beide.

Het artifact-pad is meestal de bottleneck

Profileer een trage pipeline en de compileerstap is zelden de grootste balk. Basis-images ophalen, caches herstellen, artifacts uploaden en het resultaat pushen vormen het grootste deel van de doorlooptijd in typische builds. Drie fixes, in volgorde van rendement: houd een registry pull-through-cache op hetzelfde private VLAN zodat lagen via het lokale netwerk komen in plaats van via het openbare internet; zet scratch op NVMe zodat het uitpakken van lagen niet seek-gebonden is; en maak de cache-sleutel precies, zodat je herstelt wat je nodig hebt in plaats van een monolitisch archief. Dichte Bergamo-cores zijn goedkoop. Wachten op het netwerk is dat niet.

Wat er mis kan gaan

  • Overlayfs op overlayfs stapelen voor Docker-in-Docker. Geneste overlay-drivers zijn traag en beschadigen af en toe lagen. Gebruik een dedicated block device in de job, of draai de builder over geneste KVM in plaats daarvan.
  • Nooit opruimen. Dangling images, build-caches en verouderde volumes vullen de scratch-NVMe in weken, en het eerste symptoom is een build die faalt op een stap die een jaar heeft gewerkt. Ruim op op een timer, niet bij een fout.
  • Cache-overdracht langer laten duren dan de buildtijd. Een dependency-cache van 3 GB die per job wordt opgehaald en gepusht, kan meer kosten dan vanaf nul compileren. Meet beide en houd de cache op hetzelfde private VLAN als de runners.

Tweak de machine

  • Al het andereNested virtualisation (VMX/SVM) · Inbegrepen
  • CPU-planningPinned physical cores · € 9
  • Opslag en encryptieZFS with hourly snapshots · € 7