Automatisierte Builds, Tests und Deployments bestimmen, wie schnell Software produktiv wird. Im „Accelerate State of DevOps Report 2024“ ordnete DORA 19 Prozent der befragten Teams der höchsten Leistungsgruppe zu: Sie deployten mehrmals täglich, benötigten weniger als einen Tag vom Commit bis zur Produktion und verzeichneten eine Change-Fail-Rate von 5 Prozent.
Diese Zahlen sind kein Hardware-Benchmark. Sie zeigen jedoch, warum kurze Warteschlangen und reproduzierbare Build-Prozesse wichtig sind. Bei dauerhaft hoher CI/CD-Last können selbst betriebene Runner feste Kapazitäten bereitstellen und laufende Cloud-Kosten besser planbar machen.
Für eine solche Infrastruktur muss nicht immer neue Hardware angeschafft werden. Servermall führt unter https://servermall.com/de/sets/gebrauchte-server/ generalüberholte Enterprise-Server verschiedener Hersteller. Laut Produktseite werden die Systeme technisch geprüft; für Server werden fünf Jahre Garantie und eine kostenfreie Lieferung innerhalb der EU angegeben. Die Konditionen sollten Käufer im konkreten Angebot bestätigen lassen.
Was ist ein Self-hosted Runner?
Ein Runner führt die einzelnen Schritte einer CI/CD-Pipeline aus: Er lädt den Quellcode, installiert Abhängigkeiten, kompiliert die Anwendung, startet Tests und erstellt Softwarepakete oder Container-Images.
Bei einem Cloud-Runner stellt der Plattformanbieter die Rechenumgebung bereit. Ein Self-hosted Runner läuft dagegen auf einem Server, den das Unternehmen selbst betreibt oder kontrolliert. Solche Systeme lassen sich unter anderem mit GitLab CI/CD, GitHub Actions, Jenkins und Azure DevOps einsetzen.
Wann lohnt sich die eigene Hardware?
Ein Self-hosted Runner ist vor allem in folgenden Situationen interessant:
- Pipelines erzeugen eine regelmäßige, gut planbare Grundlast.
- Builds benötigen viele CPU-Kerne oder viel Arbeitsspeicher.
- Große Artefakte werden innerhalb des Unternehmensnetzes verarbeitet.
- Tests müssen auf interne Datenbanken oder Geräte zugreifen.
- Spezielle Betriebssysteme, Treiber oder Erweiterungskarten werden benötigt.
- Die Build-Umgebung soll vollständig kontrolliert werden.
Bei wenigen oder stark schwankenden Builds bleibt ein Cloud-Angebot häufig einfacher. Eigene Hardware verursacht schließlich Aufwand für Updates, Überwachung, Stromversorgung und Wartung.
Warum gebrauchte Enterprise-Server passen können
Build-Prozesse profitieren häufig von vielen parallelen CPU-Kernen, ausreichend RAM und schnellen Laufwerken. Generalüberholte Enterprise-Server können diese Ressourcen zu niedrigeren Investitionskosten als aktuelle Neusysteme bereitstellen.
Besonders interessant sind sie für Entwicklungs-, Test- und Build-Umgebungen, bei denen ein einzelner Hardwareausfall nicht unmittelbar den Geschäftsbetrieb stoppt. Quellcode und Pipeline-Konfigurationen müssen dafür außerhalb des Runners gespeichert sein. Fehlgeschlagene Jobs lassen sich anschließend auf einem anderen System erneut starten.
Der Begriff „gebraucht“ allein sagt allerdings wenig über die Qualität aus. Unternehmen sollten Prüfverfahren, Konfiguration, Garantie, Ersatzteilversorgung und Energiebedarf bewerten.
CPU-Bedarf anhand realer Pipelines bestimmen
Mehrere unabhängige Jobs lassen sich meist gut auf viele Kerne verteilen. Ein einzelner Build-Schritt kann dagegen stärker von einer hohen Leistung pro Kern profitieren. Deshalb sollte das Team mindestens zwei bis vier Wochen lang messen:
- Anzahl der Pipeline-Läufe pro Tag;
- maximale Zahl gleichzeitig wartender Jobs;
- CPU-Auslastung während Builds und Tests;
- mittlere und maximale Pipeline-Laufzeit;
- Wartezeit bis zum Start eines Jobs.
Das Ziel ist nicht die größtmögliche Zahl von Prozessorkernen, sondern eine kurze und vorhersehbare Warteschlange.
Arbeitsspeicher mit einer einfachen Formel planen
Der Bedarf ergibt sich aus Arbeitsspeicher pro Job × maximale Parallelität plus Reserve für Host-System, Container-Runtime und Cache. Benötigt ein Build beispielsweise 4 GB und sollen acht Jobs gleichzeitig laufen, sind bereits 32 GB belegt. Mit Host und Reserve ist eine Konfiguration mit 48 bis 64 GB realistischer.
Beginnt der Server während der Pipeline Daten auf ein Laufwerk auszulagern, steigt die Laufzeit meist deutlich. Die Berechnung muss deshalb mit den tatsächlichen Projekten getestet werden.
Schneller Storage verkürzt Build-Zeiten
CI/CD erzeugt viele Lese- und Schreibzugriffe: Quellcode wird ausgecheckt, Abhängigkeiten werden entpackt und Container-Layer erzeugt. SSD- oder NVMe-Speicher eignet sich daher für Arbeitsverzeichnisse und häufig verwendete Caches.
Bei GitLab Runner lässt sich der Speicherbedarf paralleler Cache-Transfers näherungsweise als Chunk-Größe × Parallelität berechnen. Laut aktueller GitLab-Dokumentation werden bei parallelen Übertragungen standardmäßig 16 MiB große Chunks verwendet. Eine zu aggressive Parallelisierung kann deshalb Netzwerk und RAM belasten.
Große, selten benötigte Artefakte können auf einem separaten Objekt- oder Netzwerkspeicher liegen. Ein RAID verbessert die Verfügbarkeit bei einem Laufwerksdefekt, ersetzt aber kein Backup.
Self-hosted Runner als Teil der Angriffsfläche
Eine Pipeline führt automatisch Code aus. Wird ein Repository oder eine Abhängigkeit manipuliert, kann dieser Code auf den Runner und erreichbare Netzwerkressourcen zugreifen. Sinnvolle Schutzmaßnahmen sind:
- Runner in einem eigenen Netzwerksegment betreiben;
- Zugriffe auf interne Dienste auf das Notwendige begrenzen;
- Secrets nur für den jeweiligen Job bereitstellen;
- Build-Umgebungen nach jedem Lauf zurücksetzen;
- öffentliche und interne Projekte voneinander trennen;
- Protokolle zentral erfassen und auswerten.
Auch die Runner-Software benötigt einen festen Update-Prozess. Laut GitHub-Dokumentation müssen Self-hosted Runner bei deaktivierten automatischen Updates innerhalb von 30 Tagen nach Veröffentlichung einer neuen Version aktualisiert werden. Andernfalls nimmt GitHub Actions keine neuen Jobs für den Runner an. Bei einem kritischen Sicherheitsupdate kann die Sperre früher erfolgen.
Persistente oder kurzlebige Runner?
Ein persistenter Runner bleibt nach einem Job bestehen. Das vereinfacht den Betrieb und ermöglicht schnelle lokale Caches. Gleichzeitig können Dateien oder Veränderungen aus einem früheren Build zurückbleiben.
Ein kurzlebiger Runner wird für einen Auftrag erstellt und danach gelöscht oder auf einen definierten Zustand zurückgesetzt. Virtuelle Maschinen und Container erleichtern dieses Verfahren. Für nicht vertrauenswürdigen Code kann eine virtuelle Maschine eine stärkere Abgrenzung als ein gewöhnlicher Container bieten.
Stromkosten vor dem Kauf berechnen
Ein Server mit durchschnittlich 250 Watt Leistungsaufnahme verbraucht bei durchgehendem Betrieb rund 2.190 kWh pro Jahr:
0,25 kW × 24 Stunden × 365 Tage = 2.190 kWh
Dieser Verbrauch wird mit dem individuellen Strompreis multipliziert. Deshalb kann ein günstiger Dual-Socket-Server über mehrere Jahre teurer sein als ein sparsameres System. Gemessen werden sollten Leerlauf, typische Build-Last und Lastspitzen – nicht nur die maximale Leistung der Netzteile.
Cloud und eigene Runner kombinieren
Eine hybride Strategie verbindet beide Betriebsmodelle. Die eigene Hardware übernimmt die tägliche Grundlast. Bei Releases oder umfangreichen Testkampagnen werden zusätzliche Cloud-Runner zugeschaltet.
Damit dies funktioniert, müssen Pipeline-Definitionen und Build-Images auf beiden Plattformen konsistent sein. Die Cloud sollte nicht erst dann eingerichtet werden, wenn die lokale Warteschlange bereits blockiert ist.
So gelingt der Einstieg
- Pipeline-Laufzeiten und Ressourcenverbrauch erfassen.
- Grundlast und seltene Spitzen getrennt betrachten.
- Schutzbedarf von Code, Secrets und Artefakten bestimmen.
- Eine Pilotumgebung mit wenigen Projekten einrichten.
- Jobs durch Container oder virtuelle Maschinen isolieren.
- Auslastung, Warteschlangen und Fehler überwachen.
- Cloud-Fallback oder einen zweiten Runner vorbereiten.
- Erst danach die endgültige Hardware dimensionieren.
Häufige Fragen
Wie viele parallele Jobs schafft ein Server?
Das hängt von CPU, RAM, Storage und den einzelnen Builds ab. Belastbare Werte liefert nur ein Test mit den realen Pipelines des Unternehmens.
Sind gebrauchte Server für produktive CI/CD-Pipelines geeignet?
Ja, sofern sie technisch geprüft wurden und Ersatzkapazität vorhanden ist. Für zeitkritische Prozesse sollten mehrere Runner oder ein Cloud-Fallback eingeplant werden.
Wann bleibt die Cloud die bessere Lösung?
Bei geringer, unregelmäßiger Last oder fehlenden Betriebskapazitäten ist ein Cloud-Runner häufig einfacher und wirtschaftlicher.
Welche Kennzahlen sollte das Team beobachten?
Besonders hilfreich sind Pipeline-Dauer, Wartezeit, Zahl paralleler Jobs, Fehlerrate sowie CPU-, RAM- und Storage-Auslastung.
Self-hosted CI/CD lohnt sich nicht allein wegen günstiger Hardware. Der Nutzen entsteht, wenn ein Unternehmen seine Build-Umgebung kontrollieren, interne Systeme sicher anbinden und eine dauerhaft hohe Grundlast abdecken möchte. Generalüberholte Server können dafür eine wirtschaftliche Basis bilden – vorausgesetzt, Leistung, Sicherheit und Betriebskosten wurden vorab gemessen.
Quellen: DORA, „Accelerate State of DevOps Report 2024“; GitHub Docs, „Self-hosted runners reference“; GitLab Docs, „Speed up job execution“.