Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Informationen zu von GitHub gehostete Runnern

GitHub bietet gehostete virtuelle Computer, um Workflows auszuführen. Der virtuelle Computer enthält eine Umgebung mit Tools, Paketen und Einstellungen, die GitHub Actions verwenden kann.

Überblick über von GitHub gehostete Runner

Runner sind die Computer, die Aufträge in einem GitHub Actions-Workflow ausführen. Beispielsweise kann ein Runner dein Repository lokal klonen, Testsoftware installieren und dann Befehle ausführen, die deinen Code auswerten.

GitHub stellt Runner bereit, mit denen du deine Aufträge ausführen kannst. Stattdessen kannst du auch eigene Runner hosten. Jeder von GitHub gehostete Runner ist eine neue VM, die von GitHub mithilfe der Runneranwendung sowie weiteren vorinstallierten Tools gehostet wird und unter Ubuntu Linux, Windows oder macOS-Betriebssystemen verfügbar ist. Wenn du einen GitHub-gehosteten Runner verwendest, werden Computerwartung und Upgrades für dich erledigt.

Verwenden eines von GitHub gehosteten Runners

Um einen von GitHub gehosteten Runner zu verwenden, musst du einen Auftrag erstellen und mithilfe von runs-on den Typ von Runner angeben, der den Auftrag verarbeiten wird, z. B. ubuntu-latest, windows-latest oder macos-latest. Eine vollständige Liste aller Runnertypen findest du unter Unterstützte Runner und Hardwareressourcen.

Wenn der Auftrag beginnt, stellt GitHub automatisch eine neue VM für diesen Auftrag bereit. Alle Schritte eines Auftrags werden auf demselben Runner ausgeführt, damit die Aktionen in diesem Auftrag Informationen über das Dateisystem austauschen können. Du kannst Workflows direkt auf der VM oder in einem Docker-Container ausführen. Wenn der Auftrag abgeschlossen ist, wird die VM automatisch außer Betrieb genommen.

Das folgende Diagramm veranschaulicht, wie zwei Aufträge in einem Workflow auf zwei unterschiedlichen von GitHub gehosteten Runnern ausgeführt werden.

Zwei Runner verarbeiten separate Aufträge

Der folgende Beispielworkflow weist zwei Aufträge namens Run-npm-on-Ubuntu und Run-PSScriptAnalyzer-on-Windows auf. Wenn dieser Workflow ausgelöst wird, stellt GitHub eine neue VM für jeden Auftrag bereit.

  • Der Auftrag namens Run-npm-on-Ubuntu wird auf einer Linux-VM ausgeführt, da der runs-on:-Wert des Auftrags ubuntu-latest lautet.
  • Der Auftrag namens Run-PSScriptAnalyzer-on-Windows wird auf einer Windows-VM ausgeführt, da der runs-on:-Wert des Auftrags windows-latest lautet.
YAML
name: Run commands on different operating systems
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  Run-npm-on-Ubuntu:
    name: Run npm on Ubuntu
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm help

  Run-PSScriptAnalyzer-on-Windows:
    name: Run PSScriptAnalyzer on Windows
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install PSScriptAnalyzer module
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module PSScriptAnalyzer -ErrorAction Stop
      - name: Get list of rules
        shell: pwsh
        run: |
          Get-ScriptAnalyzerRule

Während der Auftrag ausgeführt wird, können Protokolle und Ausgabe in der Benutzeroberfläche von GitHub angezeigt werden:

Auftragsausgabe auf der Actions-Benutzeroberfläche

Die GitHub Actions Läufer-Anwendung ist Open Source. Du kannst im Runner-Repository mitwirken und Dateiprobleme einreichen.

Unterstützte Runner und Hardwareressourcen

Hinweis: GitHub bietet zudem larger runner, die in größeren Konfigurationen verfügbar sind. Weitere Informationen findest du unter Computerspezifikationen für larger runner.

Hardwarespezifikation für Windows- und Linux-VMs:

  • CPU mit 2 Kernen (x86_64)
  • 7 GB RAM
  • 14 GB SSD-Speicher

Hardwarespezifikation für macOS-VMs:

  • CPU mit 3 Kernen (x86_64)
  • 14 GB RAM
  • 14 GB SSD-Speicher
Runner-Image YAML-Workflow-Kennzeichnung Hinweise
Windows Server 2022 windows-latest oder windows-2022 Die windows-latest-Bezeichnung verwendet derzeit das Windows Server 2022-Runner-Image.
Windows Server 2019 windows-2019
Ubuntu 22.04 ubuntu-latest oder ubuntu-22.04 Die ubuntu-latest-Bezeichnung verwendet derzeit das Ubuntu 22.04-Runner-Image.
Ubuntu 20.04 ubuntu-20.04
Ubuntu 18.04 [veraltet] ubuntu-18.04 Migriere zu ubuntu-20.04 oder ubuntu-22.04. Weitere Informationen findest du in diesem Blogbeitrag auf GitHub.
macOS Monterey 12 macos-latest oder macos-12 Die macos-latest-Bezeichnung verwendet derzeit das macOS 12-Runner-Image.
macOS Big Sur 11 macos-11
macOS Catalina 10.15 [veraltet] macos-10.15 Migriere zu macOS-11 oder macOS-12. Weitere Informationen findest du in diesem Blogbeitrag auf GitHub.

Hinweis: Die -latest-Runner-Images sind die neuesten stabilen Images, die GitHub bereitstellt, und entsprechen möglicherweise nicht der neuesten Version des Betriebssystems, die beim Betriebssystemanbieter erhältlich ist.

Warnung: Beta- und veraltete Images werden „wie gesehen“, „mit allen Mängeln“ und „wie verfügbar“ bereitgestellt und sind von der Vereinbarung zum Servicelevel und der Garantie ausgeschlossen. Beta-Images werden möglicherweise nicht vom Kundendienst abgedeckt.

Workflowprotokolle listen den Runner auf, der zum Ausführen eines Auftrags verwendet wird. Weitere Informationen findest du unter Aufrufen des Workflowausführungsverlaufs.

Unterstützte Software

Die Softwaretools, die in GitHub-gehosteten Runnern enthalten sind, werden wöchentlich aktualisiert. Der Updatevorgang dauert mehrere Tage, und die Liste der vorinstallierten Software im main-Branch wird nach Abschluss der gesamten Bereitstellung aktualisiert.

Vorinstallierte Software

Workflowprotokolle enthalten einen Link zu den vorinstallierten Tools für den jeweiligen Runner. Um diese Informationen im Workflowprotokoll zu finden, erweitere den Abschnitt Set up job. Erweiter unter diesem Abschnitt den Abschnitt Runner Image. Der auf Included Software folgende Link beschreibt die vorinstallierten Tools auf dem Runner, der den Workflow ausgeführt hat. Link zu installierter Software Weitere Informationen findest du unter Anzeigen des Verlaufs der Workflowausführung.

Die Gesamtliste der enthaltenen Tools für jedes Runnerbetriebssystem findest du unter den folgenden Links:

GitHub-gehostete Runner enthalten zusätzlich zu den oben aufgeführten Paketen die standardmäßig integrierten Tools des Betriebssystems. Ubuntu- und macOS-Runner umfassen beispielsweise grep, find und which sowie weitere Standardtools.

Du kannst auch eine Softwarestückliste (Software bill of materials, SBOM) für jeden Build der Windows- und Ubuntu-Runnerimages anzeigen. Weitere Informationen findest du unter Überprüfen der Lieferkette für selbstgehostete GitHub-Runner.

Verwenden vorinstallierter Software

Es wird empfohlen, Aktionen zu verwenden, um mit der Software zu interagieren, die auf Runnern installiert ist. Dieser Ansatz hat mehrere Vorteile:

  • In der Regel bieten Aktionen flexiblere Funktionen wie Versionsauswahl sowie die Möglichkeit, Argumente und Parameter zu übergeben.
  • Dies stellt sicher, dass die in deinem Workflow verwendeten Toolversionen unabhängig von Softwareupdates gleich bleiben.

Wenn ein Tool vorhanden ist, das du anfordern möchtest, öffne ein Issue unter actions/runner-images. Dieses Repository enthält auch Ankündigungen zu allen wichtigen Softwareupdates auf Runnern.

Installieren zusätzlicher Software

Du kannst zusätzliche Software auf von GitHub gehosteten Runnern installieren. Weitere Informationen findest du unter Anpassen von von GitHub gehosteten Runnern.

Cloudhosts, die von GitHub gehosteten Runnern genutzt werden

GitHub hostet Linux- und Windows-Runner auf den Standard_DS2_v2-VMs in Microsoft Azure, auf denen die Runneranwendung von GitHub Actions installiert ist. Die Runner-Anwendung auf GitHub-gehosteten Runnern ist eine Fork-Kopie des Azure-Pipelines-Agenten. Bei Azure werden eingehende ICMP-Pakete werden für alle virtuellen Maschinen blockiert, so dass die Befehle ping und traceroute möglicherweise nicht funktionieren. Weitere Informationen zu den Standard_DS2_v2-Ressourcen findest du in der Microsoft Azure-Dokumentation unter Dv2- und DSv2-Serie.

GitHub hostet macOS-Runner in der eigenen macOS-Cloud von GitHub.

Workflowkontinuität

Wenn GitHub Actions-Dienste vorübergehend nicht verfügbar sind, wird eine Workflowausführung verworfen, wenn sie nicht innerhalb von 30 Minuten nach dem Auslösen in die Warteschlange gestellt wurde. Wenn beispielsweise ein Workflow ausgelöst wird und die GitHub Actions-Dienste für 31 Minuten (oder länger) nicht verfügbar sind, wird die Workflowausführung nicht verarbeitet.

Wenn die Workflowausführung erfolgreich in die Warteschlange eingereiht wurde, aber nicht innerhalb von 45 Minuten von einem GitHub-gehosteten Läufer verarbeitet wurde, wird die Workflowausführung in der Warteschlange verworfen.

Administratorrechte

Die Linux- und macOS-VMs werden beide mit dem kennwortlosen Befehl sudo ausgeführt. Wenn du Befehle ausführen oder Tools installieren musst, die höhere Berechtigungen als die des aktuellen Benutzers erfordern, kannst du sudo verwenden, ohne ein Kennwort angeben zu müssen. Weitere Informationen findest du im Sudo-Leitfaden.

Die virtuellen Windows-Maschinen sind so konfiguriert, dass sie als Administratoren laufen, wobei die Benutzerkonten-Steuerung (UAC) deaktiviert ist. Weitere Informationen findest du unter Funktionsweise der Benutzerkontensteuerung in der Windows-Dokumentation.

IP-Adressen

Hinweis: Wenn du eine Positivliste mit IP-Adressen für dein Organisations- oder Unternehmenskonto auf GitHub verwendest, kannst du keine GitHub-gehosteten Runner verwenden, sondern benötigst stattdessen selbstgehostete Runner. Weitere Informationen findest du unter „Informationen zu selbstgehosteten Runnern“.

Um eine Liste der IP-Adressbereiche abzurufen, die GitHub Actions für von GitHub gehostete Runner verwendet, kannst du die GitHub-REST-API verwenden. Weitere Informationen findest du im actions-Schlüssel in der Antwort des Endpunkts Abrufen von GitHub-Metainformationen.

Windows- und Ubuntu-Runner werden in Azure gehostet und weisen daher die gleichen IP-Adressbereiche wie Azure-Rechenzentren auf. macOS-Runner werden in der eigenen macOS-Cloud von GitHub gehostet.

Da es so viele IP-Adressbereiche für von GitHub gehostete Runner gibt, wird nicht empfohlen, diese als Positivlisten für deine internen Ressourcen zu verwenden.

Die Liste der GitHub Actions-IP-Adressen, die von der API zurückgegeben werden, wird ein Mal pro Woche aktualisiert.

Dateisysteme

GitHub führt Aktionen und Shell-Befehle in bestimmten Verzeichnissen auf der virtuellen Maschine aus. Die Dateipfade auf virtuellen Maschinen sind nicht statisch. Verwende die Umgebungsvariablen, die GitHub bereitstellt, um Dateipfade für die Verzeichnisse home, workspace und workflow zu erstellen.

VerzeichnisUmgebungsvariableBESCHREIBUNG
homeHOMEEnthält benutzerbezogene Daten. In diesem Verzeichnis können sich beispielsweise die Anmeldeinformation aus einem Anmeldeversuch befinden.
workspaceGITHUB_WORKSPACEAktionen und Shell-Befehle werden in diesem Verzeichnis ausgeführt. Eine Aktion kann den Inhalt dieses Verzeichnisses ändern, auf den dann nachfolgende Aktionen zugreifen können.
workflow/event.jsonGITHUB_EVENT_PATHDie POST-Nutzdaten des Webhookereignisses, das den Workflow ausgelöst hat. GitHub schreibt dies bei jeder ausgeführten Aktion neu, sodass der Dateiinhalt zwischen den Aktionen isoliert wird.

Eine Liste der Umgebungsvariablen, die GitHub für jeden Workflow erstellt, findest du unter Variablen.

Docker-Container-Dateisystem

Aktionen, die in Docker-Containern ausgeführt werden, haben statische Verzeichnisse unter dem Pfad /github. Wir empfehlen jedoch dringend, die Standard-Umgebungsvariablen zu verwenden, um Dateipfade in Docker-Containern zu erstellen.

In GitHub ist das Pfadpräfix /github reserviert, und es werden drei Verzeichnisse für Aktionen erstellt.

  • /github/home
  • /github/workspace: Hinweis: GitHub Actions müssen vom standardmäßigen Docker-Benutzer (Root) ausgeführt werden. Stelle sicher, dass dein Dockerfile nicht die USER-Anweisung festlegt, andernfalls kannst du nicht auf GITHUB_WORKSPACE zugreifen.
  • /github/workflow

Weitere Informationsquellen