Zum Inhalt

GitHub vorbereiten (GitHub-Variante)

Verwende diese Seite, wenn die Repositories und pipelines des Kunden auf GitHub liegen. Die Phasen sind dieselben wie bei Azure DevOps. Nur die Vorbereitung unterscheidet sich: eine GitHub App statt Tokens, federated credentials statt service connections mit Secrets, environments statt Azure-DevOps-environments und ein anderer Weg zu selbst gehosteten runners.

Thema Azure DevOps GitHub
Anmeldung bei Azure Service connection (Identität vorbereiten) Service Principal mit federated credentials (OIDC), unten beschrieben
Das Code-Repository auschecken Service connection zum Host (mcp-code) GitHub App mit einem kurzlebigen Installation-Token
Produktionsfreigabe Environment mit Genehmigern Environment mit Required Reviewers
Runners Managed DevOps Pool (Agents vorbereiten) Siehe Runners
Repository-Setup Repositories vorbereiten Dieselbe Seite, GitHub-Abschnitte

Voraussetzungen in der Organisation

Das Plattform-Team braucht die Organisationsrollen CI/CD admin und App Manager und muss Repositories erstellen können. Siehe Voraussetzungen und die GitHub-Prüfungen dort.

GitHub App für die Workflows

Die Workflows verwenden keine Personal Access Tokens. Sie erstellen ein kurzlebiges Installation-Token für eine GitHub App (actions/create-github-app-token) und übergeben es an Terraform (TF_VAR_github_token).

  1. Erstelle eine GitHub App in der Organisation oder verwende eine bestehende weiter. Gib ihr einen Namen und eine Beschreibung, die zeigen, dass sie von den Plattform-Workflows verwendet wird.
  2. Repository-Berechtigungen: Lesezugriff auf Code und Metadaten, Lese- und Schreibzugriff auf Workflows.
  3. Speichere die App ID als Organisationsvariable cloud_platform_gh_app_id und den Private Key als Organisations-Secret cloud_platform_gh_app_private_key (Pipelines).
  4. Installiere die App in der Organisation mit Only select repositories und wähle nur die Code-Repositories aus.
  5. Speichere eine Kopie des Private Key im Secret Store des Plattform-Teams, zusammen mit Namen und ID der App.

Wenn spokes die GitHub-Extension verwenden, braucht die App mehr Berechtigungen (Spoke-Integrationen vorbereiten). Wenn Terraform-Module von einem GitHub-Enterprise-Host heruntergeladen werden, siehe Zugriff auf Modulquellen.

Das ist eine andere App als die, die das Code-Repository synchronisiert (Repositories vorbereiten). Du kannst sie zusammenlegen, wenn deine Security-Regeln es erlauben, aber getrennte Apps halten die Berechtigungen klein.

Wenn mcp.json einen GitHub-Abschnitt hat (AppId, AppInstallationId, AppPrivateKeySecretName), verweist er auf die GitHub App, die die selbst gehosteten runners registriert (Config).

Federated credentials

Mit federated credentials meldet sich der Workflow ohne gespeichertes Secret bei Azure an. Füge dem Deployment-Service-Principal für jedes Konfigurations-Repository drei credentials hinzu (Microsoft Entra ID, App registrations, die App, Certificates & secrets, Federated credentials, Add credential, Szenario GitHub Actions deploying Azure resources):

Credential Entity type Subject identifier
Branch Branch repo:<organization>/<repository>:ref:refs/heads/main
Production Environment, prod repo:<organization>/<repository>:environment:prod
Canary Environment, canary repo:<organization>/<repository>:environment:canary
  • Issuer. Für GitHub.com ist es https://token.actions.githubusercontent.com. Für GitHub Enterprise auf einer eigenen Domain (<domain>.ghe.com) ist es https://token.actions.<domain>.ghe.com. Die Namen von Organisation und Repository sind die aus der Repository-URL.
  • Während der Implementierung, wenn der Default-branch initial ist, erstelle das Branch-credential für initial. Ändere es auf main, wenn die Implementierung abgeschlossen ist (Repositories vorbereiten).
  • Trage die Client-ID des Service Principals in Azure.TerraformState.Hub.ServicePrincipalId (und .Spoke.) in mcp.json ein.

Secrets in älteren Workflows

Ältere Entry-Workflows (main.yaml) lesen statt mcp.json diese Repository-Secrets:

Secret Wert
AZURE_CLIENT_ID Client-ID des Service Principals
AZURE_TENANT_ID Tenant-ID
AZURE_SUBSCRIPTION_ID Management-subscription der Plattform-Umgebung
AZURE_RG_NAME, AZURE_SA_NAME Resource group und Storage-Account des Terraform-state
AZURE_SA_CONTAINER_NAME State-Container (für spokes wird ein anderer Container verwendet)
AZURE_SA_LOG_CONTAINER_NAME Container für Deployment-Logs

Environments

Erstelle die environments canary und prod in jedem Konfigurations-Repository, dazu approval-required, wenn du die Approve*-Modi verwendest (Pipelines). Für prod und approval-required:

  • Required Reviewers: die Genehmigergruppe, die Lesezugriff auf die Repositories haben muss,
  • Prevent self-review an,
  • Allow administrators to bypass configured protection rules aus.

Ohne Reviewers auf approval-required läuft der Genehmigungsschritt weiter, ohne zu warten.

Runners

Aktueller Ansatz

Die Workflows infrastructure und container der Plattform deployen die Job runners, wie bei Azure DevOps (Agents vorbereiten). Die Registrierung der runners verwendet die GitHub App in mcp.json. Das Deployment des hub läuft auf diesen runners.

Älterer Ansatz: GitHub-hosted runners mit Virtual-Network-Integration

Frühere Versionen deployten den hub in zwei Phasen mit einem ghrunners-layer. Der layer ist nicht Teil der aktuellen hub-pipeline; dieser Abschnitt ist für Tenants, die noch die älteren Workflows verwenden.

  1. Phase 1, Standard-runners. Die ersten layers (foundation, connectivity, ghrunners) laufen auf einer standardmäßigen GitHub-hosted runner group (ein runner mit dem aktuellen Ubuntu-Image, zum Beispiel 2 Kerne, 8 GB, 75 GB Disk), weil noch kein Netzwerk existiert. Richte defaultRunnerGroup in .github/workflows/main.yaml auf diese Gruppe aus.
  2. Phase 2, runners mit Virtual-Network-Integration. Sobald das Netzwerk existiert, erstelle runners, die darin leben:

    1. Ermittle die Database-ID der Organisation oder des Enterprise:

      gh auth login -s 'read:enterprise'
gh api graphql -f query='query($login: String!) { organization(login: $login) { login databaseId } }' -f login='<organization>'

      Für ein Enterprise frage stattdessen enterprise (slug: $slug) ab. Für einen ghe.com-Host füge --hostname <subdomain>.ghe.com hinzu. 2. Registriere in der connectivity-subscription den Resource Provider GitHub.Network, delegiere das runner-Subnetz an GitHub.Network/networkSettings und erstelle die Network-Settings-Ressource (Typ GitHub.Network/networkSettings, mit der Subnetz-ID und der Database-ID als businessId). Mach das für canary und für prod. Verwende eine Region, die das Networking der GitHub-hosted runners unterstützt (das Runbook verwendete North Europe, weil West Europe damals nicht unterstützt wurde; prüfe die aktuelle Liste). 3. Erstelle in den Organisationseinstellungen unter Hosted compute networking für jede Plattform-Umgebung eine network configuration mit der Ressourcen-ID der Network-Settings. Wenn die Option deaktiviert ist, muss der Enterprise-Owner sie aktivieren. Wenn das Formular einen JSON-Fehler zurückgibt, warte ein paar Minuten und versuche es erneut. 4. Erstelle pro Umgebung eine runner group (zum Beispiel lz-canary und lz-prod) mit dieser network configuration und Zugriff für die vier Repositories, und in jeder Gruppe einen GitHub-hosted runner. Warte, bis der runner-Status Ready ist. 3. Stelle defaultRunnerGroup in main.yaml auf die neue Gruppe um und führe dann die übrigen layers der Reihe nach aus: firewall, identity, management, postdeployment. 4. Füge Firewallregeln hinzu, damit die runners erreichen, was sie brauchen, wie unter Netzwerkzugriff der Agents.

Siehe auch Die Plattform deployen.