Ein GitHub Actions Workflow läuft nicht im luftleeren Raum – er benötigt eine Ausführungsumgebung. Diese Umgebung wird durch sogenannte Runner bereitgestellt: virtuelle oder physische Maschinen, die Jobs aus Workflows entgegennehmen und ausführen. Die Architektur ist bewusst entkoppelt: Während der Workflow-Code im Repository liegt, wird die eigentliche Ausführung auf dedizierte Runner-Maschinen ausgelagert.
GitHub unterscheidet dabei zwei grundlegende Typen: von GitHub gehostete Runner und selbst gehostete Runner. Dieser Unterschied ist nicht nur technischer Natur, sondern hat weitreichende Konsequenzen für Wartung, Sicherheit und Kosten. In diesem Kapitel konzentrieren wir uns auf die von GitHub gehosteten Runner, die für die meisten Anwendungsfälle die pragmatischste Lösung darstellen.
GitHub stellt standardmäßig eine vollständig verwaltete Runner-Infrastruktur bereit. Diese Runner sind virtuelle Maschinen, die GitHub in seiner Cloud-Umgebung betreibt und wartet. Der entscheidende Vorteil: Sie müssen sich nicht um Provisionierung, Updates oder Wartung kümmern – GitHub übernimmt das komplette Lifecycle-Management.
Ein wichtiges Detail: Mit Ausnahme der Single-CPU-Runner erhält jeder Job eine frische virtuelle Maschine. Nach Abschluss des Jobs wird diese VM wieder zerstört. Single-CPU-Runner bilden hier eine Ausnahme – sie laufen in Containern auf geteilten VMs, was Ressourcen spart, aber auch bedeutet, dass die Isolation nicht ganz so strikt ist.
GitHub bietet Runner für die drei gängigen Betriebssystem-Familien:
| Betriebssystem | Architektur | Typische Anwendungsfälle |
|---|---|---|
| Ubuntu Linux | x64, ARM64 | Web-Anwendungen, Container-Builds, Backend-Services |
| Windows | x64 | .NET-Anwendungen, Windows-spezifische Tools |
| macOS | x64, ARM64 (M-Serie) | iOS/macOS-Apps, Swift-Projekte |
Die ARM64-Images für Linux werden dabei nicht direkt von GitHub,
sondern von Partnern bereitgestellt und im Repository
actions/partner-runner-images verwaltet. Dies ist ein
Zugeständnis an die wachsende Bedeutung von ARM-Architekturen,
insbesondere im Cloud- und Edge-Computing-Bereich.
Die Standard-Runner von GitHub decken viele Anwendungsfälle ab, stoßen aber bei rechenintensiven Builds schnell an ihre Grenzen. Für Organisationen mit GitHub Team- oder Enterprise Cloud-Plan bietet GitHub daher Larger Runner an – virtuelle Maschinen mit mehr CPU-Kernen, RAM oder sogar GPU-Unterstützung.
Die Unterscheidung ist nicht nur eine Frage der Geschwindigkeit. Larger Runner ermöglichen Workflows, die auf Standard-Runnern schlicht nicht praktikabel wären: das Training von Machine-Learning-Modellen, intensive Videoverarbeitung oder parallelisierte Test-Suites mit Hunderten von Tests. GPU-basierte Runner eröffnen zusätzlich Möglichkeiten für CUDA-basierte Workloads oder Hardware-beschleunigte Rendering-Prozesse.
Ein praktisches Beispiel: Ein Standard-Runner mit zwei CPU-Kernen benötigt für einen vollständigen Build einer großen TypeScript-Codebase möglicherweise 20 Minuten. Ein Larger Runner mit 16 Kernen kann denselben Build durch Parallelisierung in unter 5 Minuten abschließen – was nicht nur Zeit spart, sondern auch die Entwicklungsgeschwindigkeit erhöht.
Jeder Runner kommt nicht als leere VM, sondern mit einer umfangreichen Softwareausstattung. GitHub pflegt und aktualisiert diese Images wöchentlich. Die Liste der installierten Tools ist beeindruckend: Compiler, Laufzeitumgebungen, Paketverwaltung, Container-Tools, Datenbanken und vieles mehr.
Nehmen wir einen Ubuntu-Runner als Beispiel: Er bringt bereits
Node.js, Python, Java, .NET, Docker, Kubectl und zahlreiche weitere
Tools mit. Die vollständige Liste wird im Repository
actions/runner-images gepflegt und dokumentiert. Das
bedeutet für Sie als Workflow-Autor: In vielen Fällen können Sie direkt
loslegen, ohne erst Zeit für die Einrichtung der Build-Umgebung
aufzuwenden.
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Direkt Python verwenden
run: |
python --version # Python ist bereits installiert
pip install -r requirements.txtDie wöchentlichen Updates werfen allerdings auch eine Frage auf: Wie
stellen Sie sicher, dass Ihr Workflow reproduzierbar bleibt, wenn sich
die Versionen der installierten Tools ändern? Die Antwort liegt in der
Verwendung von Actions. GitHub empfiehlt ausdrücklich,
Tools nicht direkt zu verwenden, sondern über Actions wie
actions/setup-node oder actions/setup-python
zu steuern. Diese Actions ermöglichen präzise
Versionsspezifikationen:
- uses: actions/setup-node@v4
with:
node-version: '18.17.0' # Exakte VersionDieser Ansatz bietet nicht nur Reproduzierbarkeit, sondern auch Flexibilität: Sie können verschiedene Versionen in Matrix-Builds testen, ohne sich um die Verfügbarkeit auf dem Runner kümmern zu müssen.
Ein besonders nützliches Detail: Jeder Workflow-Log enthält einen direkten Link zur exakten Software-Konfiguration des verwendeten Runners. Im Bereich “Set up job” finden Sie unter “Runner Image” einen Link, der die installierte Software im Detail auflistet. Das ist wertvoll für Debugging-Zwecke – wenn ein Build plötzlich fehlschlägt, können Sie nachvollziehen, ob sich die Runner-Konfiguration geändert hat.
Zusätzlich bietet GitHub für Windows- und Ubuntu-Runner eine Software Bill of Materials (SBOM) an. Diese maschinenlesbare Auflistung aller Softwarekomponenten ist besonders in regulierten Branchen wichtig, wo Sie nachweisen müssen, welche Softwareversionen in Ihrem Build-Prozess verwendet wurden.
Während die Standard-Images vielseitig sind, gibt es Szenarien, in denen Sie mehr Kontrolle benötigen. Vielleicht müssen Sie spezifische Sicherheitspatches vorab einspielen, lizenzierte Software bereitstellen oder eine konsistente Unternehmens-Standardumgebung garantieren. Hier kommen Custom Images ins Spiel.
Custom Images sind maßgeschneiderte VM-Images, die auf den von GitHub bereitgestellten Basis-Images aufbauen. Sie können diese Images mit Ihren eigenen Tools, Abhängigkeiten, Zertifikaten und Konfigurationen anreichern. Der Clou: Sie definieren den Build-Prozess für Ihr Custom Image selbst als GitHub Actions Workflow. Meta, aber effektiv.
Die Vorteile liegen auf der Hand:
Supply Chain Control: Sie bestimmen exakt, welche Software in welcher Version auf Ihren Runnern läuft. Das reduziert externe Abhängigkeiten und verbessert die Sicherheit.
Performance: Wenn Ihre Workflows regelmäßig große Abhängigkeiten installieren müssen, können Sie diese direkt ins Image einbacken. Ein Node.js-Projekt mit Hunderten von npm-Paketen profitiert erheblich, wenn diese bereits vorinstalliert sind.
Konsistenz: Alle Ihre Workflows verwenden dieselbe, validierte Basis-Umgebung. Das eliminiert das Problem “funktioniert bei mir”, das aus unterschiedlichen Entwicklungs- und Build-Umgebungen resultiert.
Ein wichtiger Hinweis: Custom Images sind ausschließlich mit Larger Runnern nutzbar und werden zum selben Minutentarif abgerechnet. Die Speicherung der Images selbst fällt unter GitHub Actions Storage und wird entsprechend berechnet.
Wo laufen die von GitHub gehosteten Runner eigentlich? Die Antwort: auf Microsoft Azure. Linux- und Windows-Runner werden als virtuelle Maschinen in Azure betrieben, macOS-Runner in Azure-Rechenzentren. Die Runner-Anwendung selbst ist ein Fork des Azure Pipelines Agent – eine pragmatische Entscheidung, die auf bewährter Infrastruktur aufbaut.
Diese Azure-Basis hat praktische Konsequenzen: ICMP-Pakete werden für
alle Azure-VMs blockiert. Das bedeutet, dass klassische
Netzwerk-Diagnose-Tools wie ping oder
traceroute nicht funktionieren werden. Wenn Sie in einem
Workflow Netzwerk-Konnektivität testen müssen, greifen Sie auf
HTTP-basierte Checks zurück.
GitHub-gehostete Runner benötigen Internetzugang mit mindestens 70 Kilobit pro Sekunde für Upload und Download. Das klingt nach wenig, ist aber relevant, wenn Sie über den Einsatz in Umgebungen mit eingeschränkter Bandbreite nachdenken. Die meisten modernen Internetverbindungen erfüllen diese Anforderung mühelos, aber in Edge-Computing-Szenarien oder speziellen Netzwerk-Setups kann das zum Thema werden.
GitHub Actions ist ein verteiltes System, und verteilte Systeme können ausfallen. Was passiert mit Ihren Workflows, wenn GitHub Actions vorübergehend nicht verfügbar ist?
Die Antwort ist differenziert: Wenn ein Workflow getriggert wird und die GitHub Actions Services nicht verfügbar sind, gibt es ein 30-Minuten-Fenster, in dem der Workflow in die Queue aufgenommen werden muss. Ist der Service länger als 30 Minuten nicht verfügbar, wird der Workflow verworfen. Das mag hart klingen, verhindert aber, dass sich eine riesige Warteschlange aufbaut, die nach einem Ausfall zu einer Überlastung führen würde.
Ein zweiter Timeout greift, wenn ein Workflow erfolgreich in die Queue aufgenommen wurde, aber nicht innerhalb von 45 Minuten von einem Runner verarbeitet wird. Auch hier wird der Workflow verworfen. Das kann in Zeiten hoher Last passieren, wenn viele Workflows gleichzeitig um verfügbare Runner konkurrieren.
Diese Timeouts sind normalerweise kein Problem, aber bei kritischen Workflows sollten Sie alternative Trigger-Mechanismen in Betracht ziehen oder Monitoring einrichten, um verworfene Workflows zu erkennen.
Ein oft übersehenes Sicherheitsfeature: GitHub provisioniert Runner
mit einer modifizierten /etc/hosts-Datei, die den
Netzwerkzugriff auf bekannte Cryptocurrency-Mining-Pools und schädliche
Websites blockiert. Domains wie MiningMadness.com oder
cpu-pool.com werden auf localhost
umgeleitet.
Warum ist das wichtig? Runner sind leistungsfähige virtuelle Maschinen mit gutem Internetzugang – attraktive Ziele für Cryptojacking-Angriffe. Kompromittierte Dependencies oder böswillige Pull Requests könnten versuchen, Runner-Ressourcen für Mining zu missbrauchen. Die etc/hosts-Blockierung ist eine zusätzliche Schutzschicht, die solche Angriffe erschwert.
Ein häufiges Szenario: Ihr Workflow muss auf Ressourcen zugreifen, die nicht öffentlich im Internet verfügbar sind. Eine interne Paketregistrierung, ein Secrets-Manager hinter der Firewall oder ein Datenbank-Service in Ihrem privaten Netzwerk. Standard-Runner von GitHub haben per Design nur Zugriff auf das öffentliche Internet – wie löst man dieses Problem?
GitHub bietet drei Ansätze:
Der eleganteste Ansatz nutzt OpenID Connect (OIDC)-Token zur Authentifizierung. GitHub Actions kann OIDC-Token ausstellen, die Ihr Workflow verwenden kann, um sich gegenüber einem API-Gateway zu authentifizieren. Das Gateway fungiert als Brücke zwischen dem öffentlichen Internet und Ihrem privaten Netzwerk.
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # Benötigt für OIDC-Token
steps:
- name: Hole OIDC-Token und authentifiziere
run: |
TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
"$ACTIONS_ID_TOKEN_REQUEST_URL" | jq -r '.value')
# Token an API-Gateway sendenDer Vorteil: Sie müssen keine langlebigen Credentials in Secrets speichern. Das OIDC-Token ist kurzlebig und workflow-spezifisch.
Wenn Sie kein separates API-Gateway betreiben möchten, bietet sich WireGuard an – ein modernes VPN-Protokoll. Sie richten einen WireGuard-Server in Ihrem privaten Netzwerk ein und lassen Ihren Workflow eine Verbindung dazu aufbauen. Dadurch entsteht ein Overlay-Netzwerk, über das der Runner direkt auf interne Ressourcen zugreifen kann.
steps:
- name: WireGuard einrichten
run: |
sudo apt-get install wireguard
echo "${{ secrets.WIREGUARD_CONFIG }}" > wg0.conf
sudo wg-quick up ./wg0.conf
- name: Zugriff auf interne Ressource
run: curl http://internal-api.company.local/healthDer Nachteil: Sie müssen die WireGuard-Konfiguration als Secret pflegen und im Workflow einrichten. Das kostet Setup-Zeit in jedem Job.
Die umfassendste Lösung ist die Integration in ein Azure Virtual Network (VNET). Wenn Sie den GitHub Team- oder Enterprise Cloud-Plan nutzen, können Sie GitHub-gehostete Runner direkt in Ihr Azure VNET einbinden. Die Runner erhalten dann Netzwerkzugriff auf alle Ressourcen im VNET, als wären sie Teil Ihrer Azure-Infrastruktur.
Dieser Ansatz bietet maximale Kontrolle: Sie definieren Netzwerk-Policies, Firewalls und Routing in Azure, und der Runner folgt diesen Regeln. Der Preis ist höhere Komplexität – Sie müssen Azure-Netzwerke verstehen und verwalten.
Welcher Ansatz passt zu Ihrem Anwendungsfall? Das hängt von Ihren Anforderungen ab:
| Ansatz | Komplexität | Kontrolle | Beste Verwendung |
|---|---|---|---|
| OIDC + API-Gateway | Mittel | Begrenzt auf definierte APIs | Selektiver Zugriff auf einzelne Services |
| WireGuard | Niedrig | Voller Netzwerkzugriff | Flexibler Zugriff ohne Azure-Abhängigkeit |
| Azure VNET | Hoch | Vollständige Netzwerk-Policies | Umfassende Integration in Azure-Infrastruktur |
Die Wahl hängt auch davon ab, wie viel Kontrolle Sie über die Netzwerk-Infrastruktur haben und ob Sie bereits Azure nutzen. Für kleinere Projekte ohne Azure-Präsenz ist WireGuard oft der pragmatischste Weg. Für Unternehmen, die stark in Azure investiert sind, ist VNET die natürliche Wahl.
Beim Einsatz von GitHub-gehosteten Runnern sollten Sie einige praktische Aspekte im Hinterkopf behalten:
Nested Virtualization ist technisch möglich, wird aber nicht offiziell unterstützt. Wenn Sie in einem Workflow Docker-in-Docker oder ähnliche verschachtelte Virtualisierung benötigen, funktioniert das meist – aber ohne Garantien für Stabilität oder Performance.
Zusätzliche Software können Sie jederzeit installieren. Der Workflow hat vollen Root-Zugriff auf die VM. Wenn ein Tool nicht vorinstalliert ist, können Sie es im Workflow-Step nachrüsten. Das kostet allerdings Zeit in jedem Lauf – ein Argument für Custom Images bei häufig benötigter Software.
Feedback und Anfragen zu Runner-Images nimmt GitHub
über das Repository actions/runner-images entgegen. Wenn
Sie ein Tool vermissen oder ein Problem mit den Standard-Images haben,
ist das der richtige Kanal.
Die Runner-Architektur von GitHub Actions ist durchdacht und für die Mehrheit der Anwendungsfälle gut geeignet. Die Standard-Runner bieten eine solide Basis, Larger Runner und Custom Images erweitern die Möglichkeiten für anspruchsvolle Szenarien, und die Optionen für private Netzwerke schaffen Flexibilität für Unternehmensumgebungen. Das Zusammenspiel dieser Komponenten macht GitHub Actions zu einer leistungsfähigen CI/CD-Plattform, die sich vom Hobby-Projekt bis zur Enterprise-Anwendung skalieren lässt.