Informationen zu selbst-gehosteten Runnern

Informationen zu selbst-gehosteten Runnern

Selbst-gehostete Läufer bieten mehr Kontrolle über Hardware, Betriebssystem und Software-Tools, als GitHub-gehostete Läufer zur Verfügung stellen. Bei selbst gehosteten Läufern kannst Du eine benutzerdefinierte Hardwarekonfiguration mit mehr Rechenleistung oder Arbeitsspeicher erstellen um größere Aufträge auszuführen, kannst Software installieren die in Deinem lokalen Netzwerk verfügbar ist und kannst ein Betriebssystem auswählen, das von GitHub-gehosteten Läufern nicht angeboten wird. Selbst gehostete Runner können physisch, virtuell, in einem Container, lokal oder in einer Cloud sein.

You can add self-hosted runners at various levels in the management hierarchy:

• Repository-level runners are dedicated to a single repository.
• Organization-level runners can process jobs for multiple repositories in an organization.
• Enterprise-level runners can be assigned to multiple organizations in an enterprise account.

Your runner machine connects to GitHub Enterprise Server using the GitHub Actions self-hosted runner application. Die GitHub Actions Läufer-Anwendung ist Open Source. Du kannst mitwirken und Issues im Läufer Repository einreichen. When a new version is released, the runner application automatically updates itself when a job is assigned to the runner, or within a week of release if the runner hasn't been assigned any jobs.

Ein selbst-gehosteter Läufer wird automatisch aus GitHub Enterprise Server entfernt, wenn er sich länger als 30 Tage nicht mehr mit GitHub Actions verbunden hat.

For more information about installing and using self-hosted runners, see "Adding self-hosted runners" and "Using self-hosted runners in a workflow."

Unterschiede zwischen GitHub-gehosteten und selbstgehosteten Runnern

GitHub-hosted runners offer a quicker, simpler way to run your workflows, while self-hosted runners are a highly configurable way to run workflows in your own custom environment.

GitHub-gehostete Runner:

• Erhalten automatische Updates für das Betriebssystem, vorinstallierte Pakete und Tools sowie die Anwendung für selbst-gehostete Runner.
• Werden von GitHub verwaltet und gepflegt.
• Stellen für jede Jobausführung eine saubere Instanz bereit.
• Verwenden freie Minuten von Ihrem GitHub-Konto. Nach Überschreiten der Freiminuten gelten Minutentarife.

Selbst-gehostete Runner:

• Erhalten automatische Updates nur für die Anwendung für selbst-gehostete Runner. You are responsible for updating the operating system and all other software.
• Kann Cloud-Dienste oder lokale Computer verwenden, für die Du bereits bezahlst.
• Können an Deine Hardware-, Betriebssystem-, Software- und Sicherheitsanforderungen angepasst werden.
• Brauchen nicht für jeden Job-Auszuführung eine saubere Instanz.
• Können GitHub Actions kostenlos verwenden, aber Du bist selbst für die Wartungskosten Deiner Runner-Maschinen verantwortlich.

Anforderungen für selbst-gehostete Runner-Maschinen

You can use any machine as a self-hosted runner as long at it meets these requirements:

• Du kannst die Anwendung für selbst-gehostete Runner auf dem Rechner installieren und ausführen. For more information, see "Supported architectures and operating systems for self-hosted runners."
• Die Maschine kann mit GitHub Actions kommunizieren. Weitere Informationen findest Du unter „Kommunikation zwischen selbst-gehosteten Runnern und GitHub“.
• Der Rechner verfügt über genügend Hardwareressourcen für den Typ der Workflows, den Du ausführen möchtest. Die Anwendung für selbst-gehostete Runner selbst erfordert nur minimale Ressourcen.
• Wenn Du Workflows ausführen willst, die Docker-Container-Aktionen oder Service-Container verwenden, brauchst Du eine Linux-Maschine und Docker muss installiert sein.

Nutzungseinschränkungen

There are some limits on GitHub Actions usage when using self-hosted runners. Die Einschränkungen können sich jederzeit ändern.

• Workflow run time (Workflow-Laufzeit) - Jede Workflow-Ausführung ist auf 72 Stunden begrenzt. Wenn eine Workflow-Ausführung diesen Grenzwert erreicht, wird die Workflow-Ausführung abgebrochen.
• Job queue time (Job-Warteschlangenzeit) - Jeder Auftrag für selbst-gehostete Läufer 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 requests (API Anfragen) - Pro Stunde kannst Du bis zu 1000 API-Anfragen über alle Aktionen innerhalb innerhalb eines Repository ausführen. Bei Überschreitung schlagen zusätzliche API-Aufrufe fehl, was dazu führen kann, dass Aufträge fehlschlagen.
• Auftrags-Matrix - Eine Auftragsmatrix kann maximal 256 Aufträge pro Workflow-Ausführung generieren. Dieses Limit gilt auch für selbst-gehostete Läufer.
• Workflow run queue - No more than 500 workflow runs can be queued in a 10 second interval per repository. If a workflow run reaches this limit, the workflow run is terminated and fails to complete.

Workflow continuity for self-hosted runners

If GitHub Actions services are temporarily unavailable, then a workflow run is discarded if it has not been queued within 30 minutes of being triggered. For example, if a workflow is triggered and the GitHub Actions services are unavailable for 31 minutes or longer, then the workflow run will not be processed.

Supported architectures and operating systems for self-hosted runners

The following operating systems are supported for the self-hosted runner application.

Linux

• Red Hat Enterprise Linux 7 or later
• CentOS 7 or later
• 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 2016 64-bit
• Windows Server 2019 64-bit

macOS

• macOS 10.13 (High Sierra) oder höher

Architectures

The following processor architectures are supported for the self-hosted runner application.

• x64 - Linux, macOS, Windows.
• ARM64 - Linux only.
• ARM32 - Linux only.

Kommunikation zwischen selbst-gehosteten Runnern und GitHub

Some extra configuration might be required to use actions from GitHub.com with GitHub Enterprise Server, or to use the actions/setup-LANGUAGE actions with self-hosted runners that do not have internet access. Weitere Informationen findest Du unter „Kommunikation zwischen selbst-gehosteten Runnern und GitHub“.

Kommunikation zwischen selbst-gehosteten Runnern und GitHub Enterprise Server

The self-hosted runner polls GitHub Enterprise Server to retrieve application updates and to check if any jobs are queued for processing. The self-hosted runner uses a HTTPS long poll that opens a connection to GitHub Enterprise Server for 50 seconds, and if no response is received, it then times out and creates a new long poll. The application must be running on the machine to accept and run GitHub Actions jobs.

You must ensure that the machine has the appropriate network access to communicate with your GitHub Enterprise Server instance.

You can also use self-hosted runners with a proxy server. For more information, see "Using a proxy server with self-hosted runners."

Sicherheit von selbst-gehosteten Runner mit öffentlichen Repositories

We recommend that you only use self-hosted runners with private repositories. This is because forks of your repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

This is not an issue with GitHub-hosted runners because each GitHub-hosted runner is always a clean isolated virtual machine, and it is destroyed at the end of the job execution.

Untrusted workflows running on your self-hosted runner pose significant security risks for your machine and network environment, especially if your machine persists its environment between jobs. Some of the risks include:

• 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.