Umstellung von selbstgehosteten Runnern auf von GitHub gehostete Runner

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

In diesem Artikel

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

In diesem Lernprogramm erfahren Sie, wie Sie Ihre aktuelle Verwendung von Läufern bewerten und dann Workflows von selbst gehosteten Läufern zu GitHub-gehosteten Läufer effizient migrieren.

1. Bewerten Sie Ihre aktuelle CI-Infrastruktur

Die Migration von selbstgehosteten Runnern zu GitHub-gehosteten größeren 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. Verwenden Sie beispielsweise in GitHub Actions Metriken zur Nutzung die Registerkarte Jobs und filtern Sie nach der Bezeichnung des Runners (wie z. B. self-hosted oder einer angepassten Bezeichnung), um zu sehen, welche Repositories 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 von GitHub gehosteten Läufertypen zu.

GitHub bietet 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 Computerspezifikation in Ihrem Bestand einer geeigneten GitHub-gehosteten Runner-Spezifikation zu.
  2. Notieren Sie sich alle selbst gehosteten Runner, für die es keinen passenden 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-gehosteten Läufer bereitstellen, schätzen Sie, 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

Konfigurieren Sie nach der Schätzung Ihrer Kapazitätsanforderungen Runner-Gruppen und Zugriffsrichtlinien so, dass Ihre GitHub-gehosteten 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. Auf diese Weise können Workflows ohne Änderungen fortgesetzt werden, wenn Sie zu GitHub-gehosteten Runner wechseln.

  2. Fügen Sie der entsprechenden Gruppe neue GitHub-hosted runners hinzu, und legen Sie Parallelitätsgrenzwerte basierend auf den verwendungsmustern 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.

Hinweis

macOS größere Runner können nicht zu Runner-Gruppen hinzugefügt werden und müssen direkt in Ihren Workflow-Dateien referenziert werden.

5. Einrichten von GitHub-gehosteten Runnern

Stellen Sie als Nächstes Ihre GitHub-gehosteten Runner basierend auf den Computertypen und der Kapazität bereit, die Sie zuvor identifiziert haben.

  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 GitHub-verwaltete Images für eine verwaltete, 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-Host-Runners innerhalb eines Azure Virtual Network (VNET) aus, um einen sicheren Zugriff auf interne Ressourcen zu gewährleisten.

  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:

  •         [AUTOTITLE](/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization)

  •         [AUTOTITLE](/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/configuring-private-networking-for-github-hosted-runners-in-your-enterprise)

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 GitHub-gehosteten Runner konfiguriert sind, aktualisieren Sie Ihre Workflow-Dateien, um sie als Ziel zu verwenden.

  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@v5
      - name: Build project
        run: make build

  3. Überprüfen Sie hartcodierte Verweise auf selbstgehostete Labels (z. B. self-hosted, linux-x64 oder benutzerdefinierte Bezeichnungen), und ersetzen Sie sie durch die entsprechenden von GitHub gehosteten Runner-Labels.

  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 GitHub-gehosteten Läufern aktualisiert und getestet wurden, entfernen Sie alle selbst gehosteten Läufer, 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 Metriken zur Nutzung von GitHub Actions die Registerkarte Jobs und filtern Sie nach der Bezeichnung des Runners (z.B. self-hosted oder Ihren angepassten Bezeichnungen), um sicherzustellen, dass keine Repositories oder Jobs noch selbst gehostete Runner verwenden.