CrestVPS

self hosted github runner

CI i runnerzy budowania

Budowania, które kończą się, zanim przełączysz kartę.

Co byśmy wdrożyli

44,03 €/mies.

62,90 €30% rocznie

Hostowane minuty CI są limitowane, kolejkowane i wolne, a krzywa kosztów robi się nieprzyjemna, gdy tylko zespół staje się produktywny. Para instancji z dedykowanymi rdzeniami i szybkim NVMe przebije większość hostowanych tierów i będzie kosztować stałą kwotę miesięcznie, niezależnie od tego, jak często pushujesz. Wirtualizacja zagnieżdżona jest w cenie, więc Docker-in-Docker i suite testowe oparte na KVM działają bez obejść.

Dlaczego ta konfiguracja

TORQUE daje liczbę rdzeni, Gen5 NVMe przepustowość artefaktów, a zagnieżdżona wirtualizacja nic nie kosztuje. Zarejestruj runnerów w swoim forgu i usuń hostowany plan.

Co byśmy wdrożyli

PlanTORQUE T2
vCPU8 (dedicated)
RAM32 GB
Dysk400 GB
Obraz systemuUbuntu Server 24.04 LTS

Rozmiar

Dwa dedykowane rdzenie i 4 GB na równoczesne zadanie to podstawa; języki kompilowane chcą 4 rdzeni i 8 GB. Węzeł TORQUE z 32 rdzeniami uruchomi więc 8 ciężkich zadań lub około 14 lekkich, nie 32. Dysk scratch ma większe znaczenie niż jedno i drugie – zaplanuj 30–50 GB na równoczesne zadanie na NVMe na warstwy obrazów, drzewa zależności i wyniki budowania. Dodaj rdzeń na węzeł, jeśli zadania wymagają zagnieżdżonej wirtualizacji. Czas oczekiwania w kolejce, a nie czas trwania zadania, pokaże, kiedy dodać węzeł.

Zagnieżdżona wirtualizacja i kiedy jej potrzebujesz

Większość CI działa dobrze w kontenerze. Trzy przypadki wymagają prawdziwego hiperwizora wewnątrz gościa: testowanie obrazów VM i cloud-init, uruchamianie emulatorów Androida lub embedded z akceleracją KVM oraz każde zadanie, w którym niezaufany pull request wykonuje kod, który nie może dotrzeć do runnera. TORQUE udostępnia SVM gościowi, więc KVM działa wewnątrz Twojego VPS, a emulator działa z natywną prędkością, a nie przez emulację programową, co daje różnicę o rząd wielkości w suite testowych Androida. Koszt to jeden rdzeń narzutu na zewnętrzny hiperwizor i nieco wolniejszy dysk w wewnętrznym gościu. Uwzględnij to w planach.

Ścieżka artefaktów jest zwykle wąskim gardłem

Profilując wolny pipeline, rzadko kiedy kompilacja jest największym słupkiem. Pobieranie obrazów bazowych, przywracanie cache, wysyłanie artefaktów i pushowanie wyników odpowiada za większość czasu rzeczywistego w typowych budowaniach. Trzy poprawki w kolejności zwrotu: trzymaj cache pull-through rejestru w tej samej prywatnej VLAN, aby warstwy docierały przez sieć lokalną, a nie publiczny internet; umieść scratch na NVMe, aby rozpakowywanie warstw nie było związane z seekiem; i sprecyzuj klucz cache, aby przywracać to, czego potrzebujesz, zamiast monolitycznego archiwum. Gęste rdzenie Bergamo są tanie. Czekanie na sieć nie jest.

Co może pójść źle

  • Układanie overlayfs na overlayfs dla Docker-in-Docker. Zagnieżdżone sterowniki overlay są wolne i czasami uszkadzają warstwy. Użyj dedykowanego urządzenia blokowego w zadaniu lub uruchom budowanie przez zagnieżdżone KVM.
  • Nigdy nie czyścimy. Wiszące obrazy, cache budowania i nieaktualne wolumeny wypełniają scratch NVMe w ciągu tygodni, a pierwszym objawem jest nieudane budowanie na kroku, który działał od roku. Czyść na timerze, nie na awarii.
  • Pozwól, aby transfer cache przekroczył czas budowania. Cache zależności o rozmiarze 3 GB pobierany i wysyłany przy każdym zadaniu może kosztować więcej niż kompilacja od zera. Zmierz oba i trzymaj cache w tej samej prywatnej VLAN co runnerzy.

Dostrojenie maszyny

  • Wszystko inneNested virtualisation (VMX/SVM) · W zestawie
  • Planowanie CPUPinned physical cores · 9 €
  • Pamięć i szyfrowanieZFS with hourly snapshots · 7 €