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 selbstgehosteten Runnern

Du kannst deine eigenen Runner hosten und die Umgebung anpassen, die für die Ausführung von Aufträgen in deinen GitHub Actions-Workflows verwendet wird.

Informationen zu selbstgehosteten Runnern

Ein selbstgehosteter Runner ist ein System, das du bereitstellst und verwaltest, um Aufträge von GitHub Actions auf GitHub Enterprise Cloud auszuführen. Weitere Informationen zu GitHub Actions findest du unter Grundlegendes zu GitHub Actions und Informationen zu GitHub Actions für Unternehmen.

Selbstgehostete Runner bieten mehr Kontrolle über Hardware, Betriebssystem und Softwaretools als von GitHub gehostete Runner. Selbstgehostete Runner bieten folgende Möglichkeiten: Erstellen von benutzerdefinierten Hardwarekonfigurationen für deine Anforderungen in Bezug auf Verarbeitungsleistung oder Arbeitsspeicher für größere Aufträge, Installieren von in deinem lokalen Netzwerk verfügbaren Softwareprogrammen, Auswählen eines Betriebssystems, das von in GitHub gehosteten Runnern nicht angeboten wird. Selbstgehostete Runner können physisch, virtuell, in einem Container, lokal oder in einer Cloud sein.

Du kannst selbstgehostete Runner auf verschiedenen Ebenen der Verwaltungshierarchie hinzufügen:

  • Runner auf Repositoryebene sind für ein einzelnes Repository vorgesehen.
  • Runner auf Organisationsebene können Aufträge für mehrere Repositorys in einer Organisation verarbeiten.
  • Runner auf Unternehmensebene können mehreren Organisationen innerhalb eines Unternehmenskontos zugewiesen werden.

Your runner machine connects to GitHub using the GitHub Actions self-hosted runner application. Die GitHub Actions Läufer-Anwendung ist Open Source. Du kannst im Runner-Repository mitwirken und Dateiprobleme einreichen. Wenn eine neue Version veröffentlicht wird, aktualisiert sich die Runneranwendung automatisch bei Zuweisung eines Auftrags zum Runner oder innerhalb einer Woche nach der Veröffentlichung, wenn dem Runner keine Aufträge zugewiesen wurden.

Ein selbstgehosteter Runner wird automatisch aus GitHub Enterprise Cloud entfernt, wenn er sich länger als 14 Tage nicht mehr mit GitHub Actions verbunden hat.
Ein kurzlebiger selbstgehosteter Runner wird automatisch aus GitHub Enterprise Cloud entfernt, wenn er sich länger als 1 Tag nicht mehr mit GitHub Actions verbunden hat.

Weitere Informationen zum Installieren und Verwenden von selbstgehosteten Runnern findest du unter Hinzufügen von selbstgehosteten Runnern und Verwenden von selbstgehosteten Runnern in einem Workflow.

Unterschiede zwischen von GitHub gehosteten und selbstgehosteten Runnern

Mit Runnern, die mithilfe von GitHub gehostet werden, können deine Workflows schneller und einfacher ausgeführt werden, während selbstgehostete Runner eine hochgradig konfigurierbare Ausführung von Workflows in deiner eigenen benutzerdefinierten Umgebung ermöglichen.

Von GitHub gehostete Runner:

  • Erhalten automatischer Updates für das Betriebssystem, vorinstallierte Pakete und Tools und die selbstgehostete Runneranwendung.
  • Werden von GitHub verwaltet und gepflegt.
  • Bereitstellen einer sauberen Instanz für jede Auftragsausführung.
  • Verwende freie Minuten von deinem GitHub-Plan. Nach Überschreiten der Freiminuten gelten Minutentarife.

Selbstgehostete Runner:

  • Empfange automatische Updates nur für die selbstgehostete Runneranwendung, obwohl du automatische Aktualisierungen des Runners möglicherweise deaktiviert hast. Weitere Informationen zum Steuern von Softwareupdates für selbstgehostete Runner findest du unter Automatische Skalierung mit selbstgehosteten Runnern. Du bist dafür verantwortlich, das Betriebssystem sowie alle weiteren Softwarekomponenten zu aktualisieren.
  • Kann Clouddienste oder lokale Computer verwenden, für die du bereits bezahlst.
  • Können an deine Hardware, das Betriebssystem, Software und Sicherheitsanforderungen angepasst werden.
  • Benötigen keine saubere Instanz für jede Auftragsausführung.
  • Sind in GitHub Actions kostenlos. Du bist jedoch für die Kosten der Wartung deiner Runnercomputer verantwortlich.
  • Können in Gruppen organisiert werden, um den Zugriff auf bestimmte -Workflows, Organisationen und Repositorys zu beschränken. Weitere Informationen findest du unter Verwalten des Zugriffs auf selbstgehostete Runner mithilfe von Gruppen.

Anforderungen für selbst-gehostete Runner-Maschinen

Du kannst jeden Computer als selbstgehosteten Runner verwenden, solange er die folgenden Anforderungen erfüllt:

Automatische Skalierung deiner selbstgehosteten Runner

Du kannst die Anzahl selbstgehosteter Runner in deiner Umgebung als Reaktion auf Webhookereignisse, die du erhältst, automatisch erhöhen oder verringern. Weitere Informationen findest du unter Automatische Skalierung mit selbstgehosteten Runnern.

Usage limits (Nutzungseinschränkungen)

Die Verwendung von GitHub Actions mit selbstgehosteten Runnern unterliegt gewissen Beschränkungen. Die Einschränkungen können sich jederzeit ändern.

  • Workflowlaufzeit: Jede Workflowausführung ist auf 35 Tage begrenzt. Wenn eine Workflow-Ausführung diesen Grenzwert erreicht, wird die Workflow-Ausführung abgebrochen. Dieser Zeitraum umfasst die Ausführungsdauer sowie die Warte- und Genehmigungszeit.
  • Zeit in der Auftragswarteschlange: Jeder Auftrag für selbstgehostete Runner kann maximal 24 Stunden lang in die Warteschlange gestellt werden. Wenn ein selbst-gehosteter Läufer die Ausführung des Auftrags nicht innerhalb dieses Limits startet, wird der Auftrag beendet und kann nicht abgeschlossen werden.
  • API-Anforderungen: Du kannst bis zu 1.000 Anforderungen an die GitHub-API pro Stunde für alle Aktionen in einem Repository ausführen. Wenn die Anzahl der Anforderungen überschritten wird, sind weitere API-Anforderungen erfolglos, was dazu führen kann, dass Aufträge erfolglos sind.
  • Auftragsmatrix: Eine Auftragsmatrix kann maximal 256 Aufträge pro Workflow-Ausführung generieren. Das Limit gilt sowohl für von GitHub Enterprise Cloud gehostete als auch selbstgehostete Runner. - Workflowausführungswarteschlange – Maximal 500 Workflowausführungen können in einem Intervall von 10 Sekunden pro Repository in die Warteschlange eingereiht werden. Wenn eine Workflowausführung diesen Grenzwert erreicht, wird die Workflowausführung beendet und kann nicht abgeschlossen werden.

Workflowkontinuität für selbstgehostete Runner

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.

Unterstützte Architekturen und Betriebssysteme für selbstgehostete Runner

Die folgenden Betriebssysteme werden für die selbstgehostete Runneranwendung unterstützt:

Linux

  • Red Hat Enterprise Linux 7 oder höher
  • CentOS 7 oder höher
  • Oracle Linux 7
  • Fedora 29 oder höher
  • Debian 9 oder höher
  • Ubuntu 16.04 oder höher
  • Linux Mint 18 oder höher
  • openSUSE 15 oder höher
  • SUSE Enterprise Linux (SLES) 12 SP2 oder höher

Windows

  • Windows 7 64-bit
  • Windows 8.1 64-Bit
  • Windows 10 64-Bit
  • Windows Server 2012 R2 64-bit
  • Windows Server 2019 64-bit

macOS

  • macOS 10.13 (High Sierra) oder höher

Architekturen

Die folgenden Prozessorarchitekturen werden für die selbstgehostete Runneranwendung unterstützt:

  • x64: Linux, macOS, Windows
  • ARM64: Linux, macOS, Windows (derzeit in der Betaphase).
  • ARM32: Linux.

Kommunikation zwischen selbst-gehosteten Runnern und GitHub Enterprise Cloud

Der selbstgehostete Runner stellt eine Verbindung mit GitHub Enterprise Cloud her, um Auftragszuweisungen zu erhalten und neue Versionen der Runneranwendung herunterzuladen. Der selbstgehostete Runner verwendet eine lange HTTPS Anfrage, die 50 Sekunden lang eine Verbindung mit GitHub Enterprise Cloud öffnet. Wird keine Antwort empfangen, wird erfolgt ein Verbindungstimeout, und eine neue lange Anfrage wird erstellt. Die Anwendung muss auf dem Computer ausgeführt werden, um GitHub Actions-Aufträge zu akzeptieren und auszuführen.

Da der selbstgehostete Runner eine Verbindung mit GitHub.com herstellt, ist es nicht nötig, dass du GitHub erlaubst, eingehende Verbindungen mit deinem selbst gehosteten Runner herzustellen.

Du musst sicherstellen, dass der Computer über angemessenen Netzwerkzugriff verfügt, um mit den unten aufgeführten GitHub-Hosts zu kommunizieren. Einige Hosts sind für wesentliche Runnervorgänge erforderlich, während andere nur für bestimmte Funktionen erforderlich sind.

Hinweis: Einige der unten aufgeführten Domänen werden mithilfe von CNAME-Einträgen konfiguriert. Für bestimmte Firewalls musst du Regeln möglicherweise rekursiv für alle CNAME-Einträge hinzufügen. Beachte, dass sich die CNAME-Einträge in Zukunft ändern können und dass nur die unten aufgeführten Domänen konstant bleiben.

Erforderlich für wesentliche Vorgänge:

github.com
api.github.com

Erforderlich für Downloadaktionen:

codeload.github.com

Erforderlich zum Hochladen/Herunterladen von Auftragszusammenfassungen und Protokollen

actions-results-receiver-production.githubapp.com
productionresultssa*.blob.core.windows.net

Erforderlich für Runnerversionsupdates:

objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

Erforderlich für den Up- und Download von Caches und Workflowartefakten:

*.blob.core.windows.net

Erforderlich für das Abrufen von OIDC-Token:

*.actions.githubusercontent.com

Erforderlich für das Herunterladen oder Veröffentlichen von Paketen oder Containern in GitHub-Paketen:

*.pkg.github.com
ghcr.io

Darüber hinaus benötigt dein Workflow möglicherweise Zugriff auf andere Netzwerkressourcen.

Wenn du eine IP-Zulassungsliste für dein GitHub-Organisations- oder -Unternehmenskonto verwendest, musst du der Zulassungsliste die IP-Adresse ihres selbstgehosteten Runners hinzufügen. Weitere Informationen findest du in der GitHub Enterprise Cloud-Dokumentation unter Verwalten zulässiger IP-Adressen für deine Organisation und Erzwingen von Richtlinien für Sicherheitseinstellungen in deinem Unternehmen."

Du kannst auch selbstgehostete Runner auch mit einem Proxyserver verwenden. Weitere Informationen findest du unter Verwenden eines Proxyservers mit selbstgehosteten Runnern.

Weitere Informationen zur Problembehandlung allgemeiner Netzwerkkonnektivitätsprobleme findest du unter Überwachung und Problembehandlung von selbstgehosteten Runnern.

Sicherheit von selbstgehosteten Runnern

Es wird empfohlen, nur selbstgehostete Runner mit privaten Repositorys zu verwenden. Der Grund hierfür liegt darin, dass Forks deines öffentlichen Repositorys möglicherweise gefährlichen Code auf deinem selbstgehosteten Runnercomputer ausführen können, indem sie einen Pull Request erstellen, der den Code in einem Workflow ausführt.

Dieses Problem besteht nicht mit von GitHub gehosteten Runnern, da jeder von GitHub gehostete Runner immer aus einer klar isolierten VM besteht und am Ende der Auftragsausführung endgültig gelöscht wird.

Nicht vertrauenswürdige Workflows auf deinem selbstgehosteten Runner stellen erhebliche Sicherheitsrisiken für deine Computer- und Netzwerkumgebung dar, insbesondere wenn deine Computerumgebung auftragsübergreifend bestehen bleibt. Beispiele für Risiken:

  • Schadprogramme, die auf dem Rechner laufen.
  • Ausbruch aus der Runner-Sandbox der Maschine.
  • Der Zugriff auf die Netzwerkumgebung der Maschine wird offengelegt.
  • Unerwünschte oder gefährliche Daten werden dauerhaft auf der Maschine gespeichert.

Weitere Informationen zur Sicherheitshärtung von selbstgehostete Runnern findest du unter Sicherheitshärten für GitHub Actions.

Weiterführende Themen