Informationen zur automatischen Skalierung
Du kannst die Anzahl selbstgehosteter Runner in deiner Umgebung als Reaktion auf Webhookereignisse, die du mit einer bestimmten Bezeichnung erhältst, automatisch erhöhen oder verringern. Beispielsweise kannst du eine Automatisierung erstellen, die jedes Mal einen neuen selbstgehosteten Runner hinzufügt, wenn du ein workflow_job
-Webhookereignis mit der queued
-Aktivität erhältst, wodurch du darüber benachrichtigt wirst, dass ein neuer Auftrag verarbeitet werden kann. Die Webhooknutzdaten enthalten Bezeichnungsdaten, damit du die Art des Runners identifizieren kannst, den der Auftrag anfordert. Nachdem der Auftrag abgeschlossen ist, kannst du eine Automatisierung erstellen, durch die der Runner als Reaktion auf die workflow_job
-completed
-Aktivität entfernt wird.
Empfohlene Lösungen für die automatische Skalierung
GitHub empfiehlt und arbeitet eng mit zwei Open-Source-Projekten zusammen, die du zum automatischen Skalieren deiner Runner verwenden kannst. Abhängig von deinen Anforderungen können eine oder beide Lösungen geeignet sein.
In den folgenden Repositorys sind detaillierte Anweisungen zum Einrichten dieser Autoskalierungen enthalten:
- actions/actions-runner-controller: Ein Kubernetes-Controller für selbstgehostete GitHub Actions-Runner
- philips-labs/terraform-aws-github-runner: Ein Terraform-Modul für skalierbare GitHub Actions-Runner auf Amazon Web Services
Jede Lösung weist bestimmte Eigenschaften auf, die du bedenken solltest.
actions-runner-controller | terraform-aws-github-runner | |
---|---|---|
Typ | Kubernetes | Linux- und Windows-VMs |
Unterstützte Clouds | Azure, Amazon Web Services, Google Cloud Platform, lokal | Amazon Web Services |
Wo Runner skaliert werden können | Auf Unternehmens-, Organisations- und Repositoryebenen. Nach Runnerbezeichnung und Runnergruppe. | Auf Organisations- und Repositoryebenen. Nach Runnerbezeichnung und Runnergruppe. |
Wie Runner skaliert werden können | Webhookereignisse, Geplant, Pull-basiert | Webhookereignisse, Geplant (Nur Runner auf Organisationsebene) |
Verwenden von kurzlebigen Runnern für die automatische Skalierung
GitHub empfiehlt die Implementierung der automatischen Skalierung mit kurzlebigen selbstgehosteten Runnern. Die automatische Skalierung mit beständigen selbstgehosteten Runnern wird nicht empfohlen. In bestimmten Fällen kann GitHub nicht garantieren, dass Aufträge keinen beständigen Runnern zugewiesen werden, während sie heruntergefahren werden. Bei kurzlebigen Runnern kann dies garantiert werden, da GitHub nur einen Auftrag pro Runner zuweist.
Mit diesem Ansatz kannst du deine Runner als kurzlebige Systeme verwalten, da du die Automatisierung dafür verwenden kannst, eine bereinigte Umgebung für jeden Auftrag bereitzustellen. Dadurch kann die Gefährdung von vertraulichen Ressourcen aus vorherigen Aufträgen begrenzt und auch das Risiko der Kompromittierung eines Runners, der neue Aufträge erhält, verringert werden.
Wenn du deiner Umgebung einen kurzlebigen Runner hinzufügen möchtest, füge den --ephemeral
-Parameter beim Registrieren deines Runners mit config.sh
ein. Beispiel:
./config.sh --url https://github.com/octo-org --token example-token --ephemeral
Der GitHub Actions-Dienst hebt die Registrierung des Runners automatisch auf, nachdem ein Auftrag verarbeitet wurde. Anschließend kannst du deine eigene Automatisierung erstellen, die den Runner löscht, sobald die Registrierung aufgehoben wurde.
Hinweis: Wenn ein Auftrag für eine bestimmte Art von Runner gekennzeichnet ist, aber kein passender Runner verfügbar ist, schlägt der Auftrag in der Warteschlange nicht sofort fehl. Stattdessen bleibt der Auftrag bis zum Ablauf des Timeoutzeitraums von 24 Stunden in der Warteschlange.
Alternativ kannst du mit der REST-API kurzlebige Just-In-Time-Runner erstellen. Weitere Informationen findest du unter Aktionen.
Steuern von Softwareupdates für selbstgehostete Runner
Standardmäßig werden Softwareupdates für selbstgehostete Runner automatisch ausgeführt, wenn eine neue Version der Runnersoftware verfügbar ist. Wenn du kurzlebige Runner in Containern verwendest, kann dies bei der Veröffentlichung einer neuen Runnerversion zu wiederholten Softwareupdates führen. Durch das Deaktivieren automatischer Updates kannst du die Runnerversion im Containerimage direkt zum gewünschten Zeitpunkt aktualisieren.
Um automatische Softwareupdates zu deaktivieren und sie selbst zu installieren, musst du das Flag --disableupdate
beim Registrieren deines Runners mit config.sh
angeben. Beispiel:
./config.sh --url https://github.com/YOUR-ORGANIZATION --token EXAMPLE-TOKEN --disableupdate
Auch wenn du automatische Updates deaktivierst, musst du deine Runnerversion regelmäßig aktualisieren. Aufgrund der neuen Funktion in GitHub Actions müssen sowohl am GitHub Actions-Dienst als auch an der Runnersoftware Änderungen vorgenommen werden. Ohne ein Softwareupdate kann der Runner möglicherweise keine Aufträge verarbeiten, bei denen die neuen Features in GitHub Actions verwendet werden.
Wenn du automatische Updates deaktivierst, musst du deine Runnerversion innerhalb von 30 Tagen nach der Veröffentlichung einer neuen Version aktualisieren. Du solltest die Benachrichtigungen zu Releases im actions/runner
-Repository abonnieren. Weitere Informationen findest du unter Benachrichtigungen konfigurieren.
Anweisungen zum Installieren der neuesten Runnerversion findest du in den Installationsanweisungen für das neueste Release.
Hinweis: Wenn du innerhalb von 30 Tagen kein Softwareupdate durchführst, reiht der GitHub Actions-Dienst keine Aufträge in die Warteschlange deines Runners ein. Wenn ein kritisches Sicherheitsupdate durchgeführt werden muss, reiht der GitHub Actions-Dienst keine Aufträge in die Warteschlange deines Runners ein, bis dieser aktualisiert wurde.
Verwenden von Webhooks für die automatische Skalierung
Du kannst mithilfe der vom workflow_job
-Webhook empfangenen Nutzdaten deine eigene Umgebung für die automatische Skalierung erstellen. Dieser Webhook ist auf Repository-, Organisations- und Unternehmensebene verfügbar, und die Nutzdaten für dieses Ereignis enthalten einen action
-Schlüssel, der den Phasen des Lebenszyklus eines Workflowauftrags entspricht, z. B. wenn Aufträge queued
, in_progress
und completed
sind. Anschließend musst du deine eigene Skalierungsautomatisierung als Reaktion auf diese Webhooknutzdaten erstellen.
- Weitere Informationen zum
workflow_job
-Webhook findest du unter Webhook-Ereignisse und -Nutzlasten. - Informationen zum Arbeiten mit Webhooks findest du unter Erstellen von Webhooks.
Authentifizierungsanforderungen
Du kannst selbstgehostete Runner für Repositorys und Organisationen mit der API registrieren und löschen. Deine Implementierung für die automatische Skalierung kann ein Zugriffstoken oder eine GitHub-App verwenden, um sich bei der API zu authentifizieren.
Dein Zugriffstoken benötigt den folgenden Geltungsbereich:
- Verwende bei privaten Repositorys ein Zugriffstoken mit dem
repo
-Geltungsbereich. - Verwende bei öffentlichen Repositorys ein Zugriffstoken mit dem
public_repo
-Geltungsbereich: - Verwende bei Organisationen ein Zugriffstoken mit dem
admin:org
-Geltungsbereich.
Um sich mithilfe einer GitHub-App zu authentifizieren, muss sie über die folgenden Berechtigungen verfügen:
- Weise für Repositorys die Berechtigung
administration
zu. - Weise für Organisationen die Berechtigung
organization_self_hosted_runners
zu.
Du kannst selbstgehostete Runner für Unternehmen mithilfe der API registrieren und löschen. Die Implementierung zur automatischen Skalierung kann ein Zugriffstoken verwenden, um sich bei der API zu authentifizieren.
Dein Zugriffstoken benötigt den manage_runners:enterprise
-Geltungsbereich.