Runner, Administration und Skalierung

Runner, Administration und Skalierung

0:00 In diesem Modul geht es um die Maschinen, auf denen alles läuft. Das klingt nach einem Administrationsthema und betrifft doch jeden im Team, denn eine Zahl entscheidet über die gefühlte Geschwindigkeit Ihrer Pipeline: die Wartezeit auf einen freien Runner. Sie taucht in keiner Laufzeitmessung auf und ist für das Team trotzdem dasselbe wie eine langsame Pipeline.

0:19 Wir sehen uns an, was GitHub anbietet, wann sich eigener Betrieb rechnet, welche Fristen dabei seit diesem Monat gelten — und wie sich das Ganze in Kubernetes automatisch skalieren lässt.

Runner, Administration und Skalierung

0:30 Fünftes Modul des dritten Tages. Drei Betriebsarten, drei Kapitel: gehostete Runner mit ihren Ausstattungen, selbst betriebene mit ihren Pflichten, und der Actions Runner Controller für den Betrieb in Kubernetes. Am Ende treffen Sie für die Beetkarte eine begründete Entscheidung — mit Zahlen, nicht mit Bauchgefühl.

GitHub-hosted Runner einsetzen

0:49 Beginnen wir mit dem Angebot von der Stange. Für die meisten Projekte ist das die richtige Wahl — und es lohnt zu wissen, was man dafür bekommt. Gehostete Runner sind virtuelle Maschinen, die GitHub für jeden Job neu bereitstellt und danach verwirft. Diese Kurzlebigkeit ist ihre wichtigste Eigenschaft — sicherheitlich wie praktisch, denn eine frische Maschine verhält sich reproduzierbar.

1:11 Ausgewählt werden sie über Labels, und neben den bekannten für Linux, Windows und macOS gibt es inzwischen ARM-Varianten und schlanke Images mit nur einem Prozessorkern. Diese Auswahl ist mehr als Kosmetik: Für einen einfachen Linting-Job brauchen Sie keine vierkernige Maschine, und in der Abrechnung macht das einen Unterschied.

1:30 Die Zahlen lohnen einen genauen Blick, und zwar wegen der rechten Spalte. In öffentlichen Repositories bekommen Sie vier Prozessorkerne und sechzehn Gigabyte Arbeitsspeicher — kostenfrei. In privaten Repositories sind es zwei Kerne und acht Gigabyte, und die Minuten werden abgerechnet. Wer also ein Projekt von öffentlich auf privat umstellt, halbiert nebenbei die Rechenleistung seiner Pipeline und wundert sich über längere Laufzeiten.

1:54 Und die vierzehn Gigabyte Plattenplatz sind bei Container-Builds mit mehreren Images schneller voll, als man denkt. Vier Gründe, und der letzte Punkt ist die eigentliche Regel. Mehr Rechenleistung hilft, wenn die Rechenleistung der Engpass ist — und das ist seltener der Fall, als man annimmt. Häufiger liegt es an fehlendem Caching oder an einem seriellen Job in der Mitte.

2:16 Was Sie mit größeren Runnern sonst nicht bekommen, sind statische Adressen für Zielsysteme mit Zugangsbeschränkung sowie ARM- und GPU-Varianten. Und der Preis ist real: Wenn Sie nicht messbar Zeit sparen, zahlen Sie nur mehr pro Minute. Der erste Punkt trifft jedes Projekt irgendwann: Das Label mit der jeweils neuesten Version wechselt bei einem Image-Update den Unterbau, und ein Build, der jahrelang lief, scheitert plötzlich.

2:40 Wer das nicht mag, nennt die Version ausdrücklich — und muss sie dann selbst pflegen. Der zweite ist die Fehldiagnose aus dem letzten Punkt. Der dritte ist der Plattenplatz. Und der vierte ist der kaufmännische, der uns im nächsten Modul wieder begegnet: Niemand sieht die Abrechnung, bis das Kontingent aufgebraucht ist und die Pipelines stehen.

Self-hosted Runner betreiben

3:00 Jetzt die eigene Hardware. Es gibt gute Gründe dafür — und seit diesem Monat auch eine Frist, die man kennen muss. Ein selbst gehosteter Runner registriert sich bei einem Repository, einer Organisation oder einem Unternehmen und nimmt Jobs entgegen. Ausgewählt wird er über Labels, und der Zugriff wird über Runner Groups geregelt — das ist die Zugriffsgrenze, die festlegt, welche Repositories diese Maschine überhaupt nutzen dürfen.

3:26 Diese Gruppen sind der wichtigste Verwaltungsbegriff dieses Kapitels. Ohne sie steht Ihre Maschine allen Repositories der Organisation offen, auch denen, die morgen erst angelegt werden. Drei gute Gründe und ein Gegenargument. Zugriff auf interne Systeme ist der häufigste — manche Zielumgebung ist aus dem Internet schlicht nicht erreichbar.

3:46 Besondere Hardware oder Lizenzen sind der zweite. Sehr hohe Last der dritte, wobei sich diese Rechnung erst bei erheblichem Volumen dreht. Und dagegen steht der Aufwand: Pflege, Updates, Absicherung — und der wird bei der Entscheidung fast immer mit null angesetzt. Rechnen Sie ihn ehrlich ein, sonst gewinnt der eigene Betrieb eine Kalkulation, die er in Wahrheit verliert.

4:09 Fünf Schritte, und die ersten drei kennen Sie aus Modul dreizehn: kurzlebig betreiben, Zugriff über Gruppen begrenzen, Netzzugang einschränken. Die Schritte vier und fünf sind neu und zeitkritisch. Neue Runner-Versionen sind binnen dreißig Tagen zu installieren, und für GitHub Enterprise Cloud beginnt am fünfundzwanzigsten September 2026 die vollständige Durchsetzung der Mindestversionen.

4:31 Dafür gibt es seit September eine Schnittstelle, die bevorstehende Abkündigungen meldet — nutzen Sie die, statt Fristen von Hand im Kalender zu führen. Der erste Punkt ist der aktuellste dieses Seminars: Ein Runner unterhalb der Mindestversion nimmt nach dem Stichtag keine Jobs mehr an — auch wenn er vorher registriert war und jahrelang lief.

4:51 Der zweite ist die häufigste Ursache dafür: Die Maschine stammt aus einem gecachten Image mit eingebackener alter Version, und die Automatisierung erzeugt sie immer wieder neu. Der dritte ist die fehlende Zugriffsgrenze. Und der vierte ist der Klassiker der ersten Inbetriebnahme, bei dem Proxy- und Zertifikatsfragen erst im ersten Job auftauchen.

Skalierung mit Kubernetes

5:10 Zum Schluss der Weg, der eigene Runner und Kurzlebigkeit zusammenbringt: ein Operator, der Runner bei Bedarf startet und danach wieder wegräumt. Der Actions Runner Controller ist ein Kubernetes-Operator für selbst gehostete Runner. Das Prinzip ist elegant: Ein Listener-Pod hält eine Verbindung zu GitHub und erfährt, wenn Jobs anstehen.

5:30 Für jeden Job entsteht ein Runner-Pod, der nach getaner Arbeit verschwindet. Damit haben Sie beides — den Netzzugang und die Hardware Ihrer eigenen Umgebung, und trotzdem die Kurzlebigkeit gehosteter Runner. Aus Sicherheitssicht ist das die beste verfügbare Antwort für selbst betriebene Runner, und deshalb lohnt sich der Aufwand für Teams mit entsprechendem Bedarf.

5:51 Diese vier Schritte laufen bei jedem einzelnen Job ab. Wichtig ist der letzte Kasten: Der Pod wird verworfen, nicht wiederverwendet. Damit ist die Frage nach Rückständen aus dem letzten Modul beantwortet — es gibt keine. Der Preis steht zwischen den Zeilen: Jeder Job braucht einen Poststart, und wenn dabei jedes Mal ein großes Image geladen wird, dauert das länger als der Job selbst.

6:14 Ein lokaler Image-Cache im Cluster ist deshalb keine Feinheit, sondern Voraussetzung für vernünftige Startzeiten. Vier Voraussetzungen, die man vor der Entscheidung kennen sollte. Ein Kubernetes-Cluster und Helm für die beiden Charts — wer beides ohnehin betreibt, hat einen kurzen Weg; wer es für die Runner erst aufbaut, sollte gut rechnen.

6:34 Je Scale Set gibt es eine zentrale Ressource, die einer Runner Group zugeordnet wird. Genug Kapazität ist der Punkt, der gern übersehen wird: Skaliert der Cluster nicht mit, wandert die Warteschlange nur von GitHub in Ihr Rechenzentrum. Und die Logs des Listeners sind die erste Anlaufstelle, wenn Jobs nicht abgeholt werden.

6:53 Der erste Punkt ist die eben beschriebene verschobene Warteschlange, nur in ihrer sichtbaren Form: Pods, die im Wartezustand hängen. Der zweite ist ein Sicherheitsthema, das man beim Einrichten leicht übergeht — Runner-Pods brauchen keine weitreichenden Cluster-Rechte, bekommen sie aber oft, weil es dann sofort funktioniert.

7:11 Der dritte ist die fehlende Zuordnung zu einer Gruppe. Und der vierte ist das Startzeitproblem mit dem Image, das Sie in der Praxis am ehesten spüren werden.

Übung

7:20 In der Übung treffen Sie eine Entscheidung — und begründen sie mit Zahlen aus echten Läufen, nicht mit Schätzungen. Drei Betriebsarten, vier Kriterien: Laufzeit, Kosten, Wartungsaufwand, Sicherheitsanforderungen. Der Hinweis ist entscheidend — die Laufzeiten stammen aus echten Läufen. Schätzungen sind an dieser Stelle wertlos, weil die Unterschiede oft kleiner sind, als man vermutet, und die Engpässe woanders liegen.

7:45 Und schreiben Sie die Entscheidung tatsächlich auf, mitsamt der Annahmen. Diese Notiz ist in einem Jahr Gold wert, wenn jemand fragt, warum die Pipeline so betrieben wird, wie sie betrieben wird. Die Schritte eins und zwei sind Messungen, drei und vier sind Überlegungen. Achten Sie bei Schritt vier auf die entscheidende Frage: Erzwingt irgendein Zugriff tatsächlich einen eigenen Runner? Wenn nicht, ist die Entscheidung meist schon gefallen.

8:11 Schritt fünf ist die Dokumentation mit Zahlen und Annahmen. Und ein praktischer Hinweis zum Vergleich in Schritt zwei: Führen Sie beide Läufe unter gleichen Bedingungen durch, sonst messen Sie den Cache und nicht die Maschine. Der erste Punkt ist die Fehldiagnose, vor der wir gewarnt haben: Der größere Runner löst ein Problem, das gar keines der Rechenleistung war.

8:31 Der zweite ist die geschönte Rechnung mit dem Wartungsaufwand bei null. Der dritte ist der Messfehler mit warmem gegen kalten Cache — er lässt einen Unterschied entstehen, wo keiner ist. Und der vierte ist der, der in Sicherheitsprüfungen auffällt: Die zusätzlichen Anforderungen an selbst betriebene Runner kommen in der Wirtschaftlichkeitsrechnung gar nicht vor.

8:51 Im letzten Modul geht es dann um die organisatorische Ebene.