Umstellung von selbstgehosteten Runnern auf von GitHub gehostete Runner

Erfahren Sie, wie Sie Ihre aktuelle CI-Infrastruktur bewerten und Workflows von selbstgehosteten Runnern zu auf GitHub gehosteten Runnern migrieren.

In diesem Artikel

Sie können Workflows auf von GitHub gehosteten oder selbst gehosteten Runnern ausführen oder eine Mischung aus Runner-Typen verwenden.

Dieses Tutorial zeigt Ihnen, wie Sie Ihren aktuellen Einsatz von Runnern bewerten und anschließend Workflows effizient von selbstgehosteten Runnern zu GitHubgehosteten Runnern migrieren.

1. Bewerten Sie Ihre aktuelle CI-Infrastruktur

Die Migration von selbstgehosteten Runnern zu größeren, von GitHub gehosteten Runnern beginnt mit einer gründlichen Bewertung Ihrer aktuellen CI-Infrastruktur. Wenn Sie sich die Zeit nehmen, Spezifikationen und Umgebungen sorgfältig abzugleichen, minimieren Sie die zeitaufwendige Behebung von Problemen, wenn Sie mit der Ausführung von Workflows auf verschiedenen Rechnern beginnen.

  1. Erstellen Sie einen Bestand jeder Computerspezifikation, die zum Ausführen von Workflows verwendet wird, einschließlich CPU-Kerne, RAM, Speicher, Chiparchitektur und Betriebssystem.
  2. Beachten Sie, ob einer der Läufer Teil einer Läufergruppe ist oder über eine Bezeichnung verfügt. Sie können diese Informationen nutzen, um die Migration von Workflows auf neue Runner zu vereinfachen.
  3. Dokumentieren Sie alle benutzerdefinierten Images und vorinstallierten Abhängigkeiten, auf die Workflows angewiesen sind, da diese Ihre Migrationsstrategie beeinflussen.
  4. Ermitteln Sie, welche Workflows derzeit auf selbst gehostete Läufer ausgerichtet sind und warum. Zum Beispiel können Sie in den GitHub Actions-Nutzungsmetriken die Registerkarte Jobs verwenden und nach der Runnerbezeichnung filtern (z. B. self-hosted oder eine benutzerdefinierte Bezeichnung), um zu sehen, welche Repositorys und Jobs diese Bezeichnung verwenden. Wenn Sie bestimmte Workflowdateien überprüfen müssen, können Sie auch die Codesuche verwenden, um Workflowdateien zu finden, die auf runs-on: self-hosted oder andere selbst gehostete Bezeichnungen verweisen.
  5. Identifizieren Sie Workflows, die auf private Netzwerkressourcen zugreifen (z. B. interne Paketregistrierungen, private APIs, Datenbanken oder lokale Dienste), da diese möglicherweise eine zusätzliche Netzwerkkonfiguration erfordern.

2. Ordnen Sie Ihre Verarbeitungsanforderungen den GitHub-gehosteten Runner-Typen zu

GitHubbietet verwaltete Läufer in mehreren Betriebssystemen – Linux, Windows und macOS – mit Optionen für GPU-fähige Computer. Weitere Informationen findest du unter Referenz für größere Läufer.

  1. Ordnen Sie jede unterschiedliche Maschinenspezifikation in Ihrem Bestand einer geeigneten GitHub-gehosteten Runner-Spezifikation zu.
  2. Notieren Sie alle selbstgehosteten Runner, für die es keinen geeigneten von GitHub gehosteten Runner gibt.
  3. Schließen Sie alle Workflows, die weiterhin auf selbst gehosteten Runnern ausgeführt werden müssen, aus Ihren Migrationsplänen aus.

3. Schätzen der Kapazitätsanforderungen

Bevor Sie GitHub-gehostete Runner bereitstellen, sollten Sie abschätzen, wie viel Rechenkapazität Ihre Workflows benötigen. Wenn Sie Ihre aktuelle selbst gehostete Läufernutzung überprüfen, können Sie geeignete Läufergrößen auswählen, Parallelitätsgrenzwerte festlegen und potenzielle Kostenänderungen vorhersagen.

  1. Klicke in der rechten oberen Ecke von GitHub auf dein Profilbild und dann auf Your organizations.

  2. Klicke auf den Namen Deiner Organisation.

  3. Klicke unter deinem Organisationsnamen auf Insights.

    Screenshot: Horizontale Navigationsleiste für eine Organisation. Eine Registerkarte mit einem Diagrammsymbol und der Bezeichnung „Erkenntnisse“ ist durch eine dunkelorange Umrandung hervorgehoben.

  4. Klicken Sie im Navigationsmenü "Insights" auf "Aktionen: Nutzungsmetriken".

  5. Klicken Sie auf die Registerkarte, die die Metriken enthält, die Sie anzeigen möchten. Weitere Informationen findest du unter Informationen zu GitHub Actions-Metriken.

  6. Überprüfen Sie die folgenden Datenpunkte, um die Kapazität der gehosteten Läufer zu schätzen:

    • Gesamt verbrauchte Minuten: Hilft Ihnen, die geplante Berechnungsnachfrage zu schätzen.
    • Anzahl der Workflowausführungen: Identifiziert Spitzenaktivitätszeiten, die möglicherweise mehr Parallelität erfordern.
    • Auftragsverteilung über Betriebssystemtypen: Stellt sicher, dass Sie die richtige Mischung aus Linux-, Windows- und macOS-Läufern bereitstellen.
    • Kennzeichnungen der Runner (Registerkarte Jobs): Filtern Sie nach einer Runner-Bezeichnung, um zu verstehen, wo eine Bezeichnung verwendet wird.

  7. Konvertieren Sie Ihre Ergebnisse in einen Kapazitätsplan:

    • Passen Sie bei Bedarf Workflows mit hoher Auslastung an größere Runnergrößen an.
    • Identifizieren Sie Workflows, die von vordefinierten oder benutzerdefinierten Images profitieren können, um die Laufzeit zu reduzieren.
    • Schätzen Sie die Parallelität, indem Sie bestimmen, wie viele Aufträge in der Regel gleichzeitig ausgeführt werden.

  8. Notieren Sie sich alle Lücken:

    • Workflows mit harten Abhängigkeiten, die Ihre aktuellen gehosteten Runner-Images nicht unterstützen.
    • Aufträge mit ungewöhnlich langen Laufzeiten oder maßgeschneiderten Umgebungsanforderungen. (Möglicherweise benötigen Sie benutzerdefinierte Bilder für diese.)

Ihr Kapazitätsplan gibt vor, wie viele Runner bereitgestellt werden sollen, welche Maschinentypen verwendet werden sollen und wie Runner-Gruppen und Richtlinien in den nächsten Schritten konfiguriert werden.

4. Konfigurieren von Runner-Gruppen und -Richtlinien

Nachdem Sie Ihre Kapazitätsanforderungen geschätzt haben, konfigurieren Sie Runner-Gruppen und Zugriffsrichtlinien, damit Ihre GitHubgehosteten Läufer für die richtigen Organisationen und Workflows verfügbar sind.

Die Konfiguration von Runner-Gruppen vor der Bereitstellung von Runnern stellt sicher, dass die Migration nicht versehentlich den Zugriff zu weit öffnet oder unerwartete Kostensteigerungen erstellt.

  1. Erstellen Sie Läufergruppen auf Unternehmensebene, um zu definieren, wer Ihre gehosteten Läufer verwenden kann. Weitere Informationen findest du unter Steuern des Zugriffs auf größere Runner.

    Verwenden Sie Runner-Gruppen, um den Zugriff nach Organisation, Repository oder Workflow festzulegen. Wenn Sie von selbst gehosteten Runnern migrieren, sollten Sie nach Möglichkeit bestehende Namen oder Bezeichnungen für Runner-Gruppen wiederverwenden. Dadurch können Workflows ohne Änderungen weiterlaufen, wenn Sie zu GitHub-gehosteten Runnern wechseln.

  2. Fügen Sie der entsprechenden Gruppe neue GitHub-gehostete Runner hinzu und legen Sie Parallelitätsgrenzwerte basierend auf den Nutzungsmustern fest, die Sie in Schritt 3 identifiziert haben. Ausführliche Informationen zur automatischen Skalierung finden Sie unter Verwalten größerer Runner.

  3. Überprüfen Sie die Richtlinieneinstellungen, um sicherzustellen, dass die Runner nur von den vorgesehenen Workflows verwendet werden. Wenn Sie beispielsweise die Verwendung auf bestimmte Repositorys beschränken oder verhindern, dass nicht vertrauenswürdige Workflows auf leistungsfähigere Computertypen zugreifen.

5. GitHub-gehostete Runner einrichten

Stellen Sie als Nächstes Ihre GitHub-gehosteten Runner basierend auf den zuvor ermittelten Maschinentypen und der Kapazität bereit.

  1. Wählen Sie die Computergröße und das Betriebssystem aus, die Ihren Workflowanforderungen entsprechen. Verfügbare Bilder und Spezifikationen finden Sie unter Referenz für größere Läufer.

  2. Weisen Sie jedem Läufer eine Läufergruppe zu, und konfigurieren Sie Parallelitätsgrenzwerte, um zu steuern, wie viele Aufträge gleichzeitig ausgeführt werden können.

  3. Wählen Sie einen Bildtyp aus:

    • Verwenden Sie von GitHub verwaltete Images für eine gepflegte, häufig aktualisierte Umgebung.
    • Verwenden Sie benutzerdefinierte Images, wenn Sie vorinstallierte Abhängigkeiten benötigen, um die Setupzeit zu reduzieren. Weitere Informationen findest du unter Verwenden von benutzerdefinierten Bildern.

  4. Wenden Sie alle erforderlichen Anpassungen an, z. B. Umgebungsvariablen, Softwareinstallation oder Startskripts. Weitere Beispiele finden Sie unter Anpassen von GitHub-gehosteten Runnern.

  5. Konfigurieren Sie optional private Netzwerke, wenn Läufer auf interne Ressourcen zugreifen müssen. Weitere Informationen findest du unter Private Netzwerke mit GitHub-gehosteten Runnern.

Konfigurieren von Optionen für private Konnektivität

Wenn Ihre Workflows Zugriff auf private Ressourcen benötigen (z. B. interne Paketregistrierungen, private APIs, Datenbanken oder lokale Dienste), wählen Sie einen Ansatz aus, der Ihren Netzwerk- und Sicherheitsanforderungen entspricht.

Konfigurieren von Azure Private Networking

Führen Sie GitHub-gehostete Runner in einem virtuellen Azure-Netzwerk (VNET) aus, um sicheren Zugriff auf interne Ressourcen zu ermöglichen.

  1. Erstellen Sie ein virtuelles Azure-Netzwerk (VNET), und konfigurieren Sie Subnetze und Netzwerksicherheitsgruppen für Ihre Läufer.
  2. Aktivieren Sie das private Azure-Netzwerk für Ihre Läufergruppe. Weitere Informationen findest du unter Konfigurieren eines privaten Netzwerks für GitHub-Runner in Ihrem Unternehmen.
  3. Wenden Sie die Netzwerkkonfiguration an, z. B. NSGs und Firewallregeln, um den Eingangs- und Ausgangsdatenverkehr zu steuern.
  4. Aktualisieren Sie die Zielausrichtung des Workflows, um die Runner Group zu verwenden, die für private Netzwerke konfiguriert ist.

Ausführliche Anweisungen finden Sie unter:

Verbinden mit einem WireGuard-Overlay-Netzwerk

Wenn das private Azure-Netzwerk nicht anwendbar ist (z. B. weil Ihr Zielnetzwerk lokal oder in einer anderen Cloud vorhanden ist), können Sie eine VPN-Überlagerung wie WireGuard verwenden, um Zugriff auf private Ressourcen auf Netzwerkebene bereitzustellen.

Ausführliche Anweisungen und Beispiele finden Sie unter Verwenden von WireGuard zum Erstellen einer Netzwerküberlagerung.

Verwenden von OIDC mit einem API-Gateway für den vertrauenswürdigen Zugriff auf private Ressourcen

Wenn Sie den Läufer nicht benötigen, um Ihrem privaten Netzwerk beizutreten, können Sie OIDC verwenden, um vertrauenswürdigen, kurzlebigen Zugriff auf einen Dienst einzurichten, den Sie über ein API-Gateway verfügbar machen. Dieser Ansatz kann den Bedarf an geheimen Schlüsseln mit langer Lebensdauer verringern und den Netzwerkzugriff auf die spezifischen Endpunkte beschränken, die Ihr Workflow benötigt.

Ausführliche Anweisungen und Beispiele finden Sie unter Verwenden eines API-Gateways mit OIDC.

6. Workflows aktualisieren, um die neuen Runner zu verwenden

Nachdem Ihre GitHubgehosteten Läufer konfiguriert wurden, aktualisieren Sie Ihre Workflowdateien so, dass sie darauf ausgerichtet werden.

  1. Verwenden Sie vorhandene Kennzeichnungen wieder, wenn Sie Ihre neuen Runner denselben Runner-Gruppennamen zugewiesen haben, die Ihre selbst gehosteten Runner verwendet haben. In diesem Fall nutzen Workflows automatisch die neuen Runner, ohne dass Änderungen erforderlich sind.

  2. Wenn Sie neue Runner-Gruppen oder Bezeichnungen erstellt haben, aktualisieren Sie das Feld runs-on in den YAML-Dateien Ihres Workflows. Beispiel:

    jobs:
  build:
    runs-on: [github-larger-runner, linux-x64]
    steps:
      - name: Checkout code
        uses: actions/checkout@v6
      - name: Build project
        run: make build

  3. Überprüfen Sie fest codierte Verweise auf Labels für selbstgehostete Runner (wie self-hosted, linux-x64 oder benutzerdefinierte Labels) und ersetzen Sie sie durch die entsprechenden Labels für von GitHub gehostete Runner.

  4. Testen Sie jeden aktualisierten Workflow, um sicherzustellen, dass er auf den neuen Läufern ordnungsgemäß ausgeführt wird. Überwachen Sie alle Probleme im Zusammenhang mit Umgebungsunterschieden oder fehlenden Abhängigkeiten.

7. Entfernen unbenutzter selbst gehosteter Runner

Nachdem Ihre Workflows auf von GitHub gehosteten Runnern aktualisiert und getestet wurden, entfernen Sie alle selbst gehosteten Runner, die nicht mehr benötigt werden. Dadurch wird verhindert, dass Aufträge versehentlich auf veraltete Infrastruktur abzielen. Weitere Informationen findest du unter Selbst-gehostete Runner entfernen.

Bevor Sie selbst gehostete Runner entfernen, vergewissern Sie sich, dass Sie vollständig migriert haben:

  • Verwenden Sie in den Nutzungsmetriken von GitHub Actions die Registerkarte Jobs, und filtern Sie nach Runner-Labeln (z. B. self-hosted oder Ihren benutzerdefinierten Labeln), um sicherzustellen, dass keine Repositories oder Jobs noch selbstgehostete Runner verwenden.