self hosted github runner
CI- und Build-Runner
Builds, die fertig sind, bevor du den Tab gewechselt hast.
Was wir bereitstellen würden
44,03 €/Mo
62,90 €−30% jährlich
Gehostete CI-Minuten sind abgerechnet, warteschlangenpflichtig und langsam, und die Kostenkurve wird hässlich, sobald ein Team produktiv ist. Ein Paar Instanzen mit dedizierten Kernen und schnellem NVMe schlägt die meisten gehosteten Tarife und kostet jeden Monat einen festen Betrag, unabhängig davon, wie oft du pushst. Nested Virtualisierung ist inklusive, also funktionieren Docker-in-Docker- und KVM-basierte Test-Suiten ohne Workaround.
Warum diese Konfiguration
TORQUE liefert die Kernzahl, Gen5-NVMe liefert den Artifact-Durchsatz, und Nested Virtualisierung kostet nichts. Registriere die Runner gegen deine Forge und lösche den gehosteten Plan.
Was wir bereitstellen würden
Sizing
Zwei dedizierte Kerne und 4 GB pro parallelem Job sind das Minimum; kompilierte Sprachen wollen 4 Kerne und 8 GB. Ein 32-Kern-TORQUE-Node läuft daher 8 schwere Jobs oder etwa 14 leichte, nicht 32. Scratch-Disk ist wichtiger als beides – plane 30-50 GB pro parallelem Job auf NVMe für Image-Layer, Abhängigkeitsbäume und Build-Ausgabe. Füge einen Kern pro Node hinzu, wenn Jobs Nested Virtualisierung benötigen. Wartezeit in der Queue, nicht die Jobdauer, zeigt dir, wann du einen Node hinzufügen solltest.
Nested Virtualisierung und wann du sie brauchst
Die meisten CI-Jobs laufen in einem Container. Drei Fälle benötigen einen echten Hypervisor im Gast: Testen von VM-Images und Cloud-Init, Ausführen von Android- oder Embedded-Emulatoren mit KVM-Beschleunigung, und jeder Job, bei dem ein nicht vertrauenswürdiger Pull Request Code ausführt, der nicht zum Runner gelangen darf. TORQUE exponiert SVM für den Gast, also funktioniert KVM in deiner VPS und der Emulator läuft mit nativer Geschwindigkeit statt durch Software-Emulation, was bei Android-Test-Suiten etwa eine Größenordnung Differenz ausmacht. Der Preis ist ein Kern Overhead für den äußeren Hypervisor und etwas langsamere Disk im inneren Gast. Plane beides ein.
Der Artifact-Pfad ist normalerweise der Flaschenhals
Profile eine langsame Pipeline und der Kompilierungsschritt ist selten der größte Balken. Basis-Images ziehen, Caches wiederherstellen, Artifacts hochladen und das Ergebnis pushen machen den Großteil der Wanduhrzeit in typischen Builds aus. Drei Fixes, in der Reihenfolge der Rendite: Halte einen Registry-Pull-through-Cache im selben privaten VLAN, damit Layer über das lokale Netzwerk statt über das öffentliche Internet ankommen; lege Scratch auf NVMe, damit das Entpacken von Layern nicht seek-gebunden ist; und mache den Cache-Key präzise, damit du wiederherstellst, was du brauchst, statt eines monolithischen Archivs. Dichte Bergamo-Kerne sind billig. Auf das Netzwerk warten ist es nicht.
Was schiefgeht
- Stacking von overlayfs auf overlayfs für Docker-in-Docker. Verschachtelte Overlay-Treiber sind langsam und korrumpieren gelegentlich Layer. Verwende ein dediziertes Blockgerät innerhalb des Jobs oder betreibe den Builder über verschachteltes KVM stattdessen.
- Nie aufräumen. Verwaiste Images, Build-Caches und veraltete Volumes füllen die Scratch-NVMe in Wochen, und das erste Symptom ist ein Build, der bei einem Schritt fehlschlägt, der seit einem Jahr funktioniert. Räume nach Zeitplan auf, nicht nach Fehler.
- Cache-Transfer länger als die Build-Zeit. Ein 3-GB-Abhängigkeits-Cache, der pro Job gepusht und gezogen wird, kann mehr kosten als von Grund auf zu kompilieren. Miss beides und halte den Cache im selben privaten VLAN wie die Runner.
Maschine optimieren
- Sonstiges — Nested virtualisation (VMX/SVM) · Inklusive
- CPU-Scheduling — Pinned physical cores · 9 €
- Speicher und Verschlüsselung — ZFS with hourly snapshots · 7 €
Mehr
Für bestimmte Aufgaben gebaut
Game-Server-Hosting
Tickrate ist ein Single-Thread-Problem. Alles andere ist Rauschen.
Trading- und Low-Latency-VPS
Distanz zur Matching-Engine und nichts zwischen dir und der Leitung.
Private VPN- und Proxy-Endpunkte
Dein eigener Exit, in einer Jurisdiktion, die du absichtlich gewählt hast.
Seedboxen und Massenspeicher
Terabytes, die günstig bleiben, und ein Port, der offen bleibt.
Kubernetes-Worker-Nodes
Günstig pro Kern, dicht und jedes Mal identisch.
KI-Inferenz und Feintuning
Eine ganze GPU, durchgereicht, zu einer Bindung, die die Rechnung aufgehen lässt.