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.

In diesem Artikel

Informationen zu selbstgehosteten Runnern

Ein selbstgehosteter Runner ist ein System, das Sie bereitstellen und verwalten, 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 länger als 14 Tage keine Verbindung mehr mit GitHub Actions hergestellt 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 Selbst-gehostete Runner hinzufügen und Verwenden von selbstgehosteten Runnern in einem Workflow.

Unterschiede zwischen GitHub-gehosteten und selbst-gehosteten Runnern

Von GitHub-gehostete Runner bieten eine schnellere und einfachere Möglichkeit zum Ausführen Ihrer Workflows, während selbstgehostete Runner eine hochgradig konfigurierbare Möglichkeit zum Ausführen von Workflows in Ihrer eigenen benutzerdefinierten Umgebung sind.

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 nur für die selbstgehostete Runneranwendung automatische Updates, obwohl du möglicherweise automatische Updates des Runners deaktiviert hast. Weitere Informationen zum Steuern von Runnersoftwareupdates für selbstgehostete Runner findest du unter Automatische Skalierung mit selbstgehosteten Runnern. Du bist für die Aktualisierung des Betriebssystems und der übrigen Software verantwortlich.
  • 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 finden Sie 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, der mindestens 24 Stunden lang in die Warteschlange war, wird abgebrochen. Die tatsächliche Zeit in der Warteschleife kann bis zu 48 Stunden vor dem Abbruch erreichen. 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: - Sie können bis zu 15.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.
  • Registrieren selbstgehosteter Runner: Du kannst maximal 10.000 selbstgehostete Runner in einer Runnergruppe haben. Wenn dieses Limit erreicht ist, ist das Hinzufügen eines neuen Runners nicht möglich.

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 8 oder höher
  • CentOS 8 oder höher
  • Oracle Linux 8 oder höher
  • Fedora 29 oder höher
  • Debian 10 oder höher
  • Ubuntu 20.04 oder höher
  • Linux Mint 20 oder höher
  • openSUSE 15.2 oder höher
  • SUSE Enterprise Linux (SLES) 15 SP2 oder höher

Windows

  • Windows 10 64-Bit
  • Windows 11, 64 Bit
  • Windows Server 2016 (64 Bit)
  • Windows Server 2019 64-bit
  • Windows Server 2022 64-Bit

macOS

  • macOS 11.0 (Big Sur) 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 public preview).
  • 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.

Die Verbindung zwischen selbstgehosteten Runnern und GitHub Enterprise Cloud verläuft über HTTPS (Port 443).

Da der selbstgehostete Runner eine Verbindung mit GitHub herstellt, darfst du nicht zulassen, dass GitHub eingehende Verbindungen mit deinem selbstgehosteten Runner herstellt.

Sie müssen sicherstellen, dass der Computer über angemessenen Netzwerkzugriff mit einer Upload- und Download-Geschwindigkeit von mindestens 70 Kilobit pro Sekunde 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.

Sie können die REST-API verwenden, um Metainformationen über GitHub abzurufen, einschließlich der IP-Adressen von GitHub-Diensten. Weitere Informationen zu den verwendeten Domänen und IP-Adressen findest du unter REST-API-Endpunkte für Metadaten.

Note

Einige der 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 aufgeführten Domänen konstant bleiben.

Erforderlich für wesentliche Vorgänge:

Shell
github.com
api.github.com
*.actions.githubusercontent.com

Erforderlich für Downloadaktionen:

Shell
codeload.github.com
pkg.actions.githubusercontent.com

Erforderlich für die Veröffentlichung unveränderlicher Aktionen:

Shell
ghcr.io

Erforderlich für den Up- und Download von Auftragszusammenfassungen, Protokollen, Workflow-Artefakten und Caches:

Shell
results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

Erforderlich für Runnerversionsupdates:

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

Erforderlich für das Abrufen von OIDC-Token:

Shell
*.actions.githubusercontent.com

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

Shell
*.pkg.github.com
ghcr.io

Benötigt für Git Large File Storage

Shell
github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

Erforderlich für Aufträge für Dependabot updates

Shell
dependabot-actions.githubapp.com

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 finden Sie unter Verwenden eines Proxyservers mit selbstgehosteten Runnern.

Weitere Informationen zur Problembehandlung allgemeiner Netzwerkkonnektivitätsprobleme findest du unter Überwachen und Behandeln von Problemen mit 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 für selbstgehostete Runner findest du unter Sicherheitshärtung für GitHub Actions.

Einschränken der Verwendung von selbstgehosteten Runnern

Unternehmens- und Organisationsbesitzerinnen können wählen, für welche Repositorys die Erstellung selbstgehosteter Runner auf Repositoryebene erlaubt ist. Benutzerinnen mit der Berechtigung „Organisationsrunner und Runnergruppen verwalten“ können nur auswählen, für welche Repositorys die Erstellung selbstgehosteter Runner auf Repositoryebene für Repositorys in Ihrer Organisation erlaubt ist.

Weitere Informationen zu benutzerdefinierten Organisationsrollen finden Sie unter „Informationen zu benutzerdefinierten Organisationsrollen“.

Weitere Informationen findest du unter Erzwingen von Richtlinien für GitHub Actions in deinem Unternehmen und unter GitHub Actions für deine Organisation Deaktivieren oder Einschränken.

Weiterführende Themen