GitHub voorbereiden (GitHub-variant)¶

Gebruik deze pagina als de repositories en pipelines van de klant op GitHub staan. De fasen zijn dezelfde als bij Azure DevOps. Alleen de voorbereiding verschilt: een GitHub App in plaats van tokens, federated credentials in plaats van service connections met secrets, environments in plaats van Azure DevOps-environments, en een andere manier om self-hosted runners te krijgen.

Onderwerp	Azure DevOps	GitHub
Inloggen bij Azure	Service connection (Identiteit voorbereiden)	Service principal met federated credentials (OIDC), hieronder beschreven
De coderepository uitchecken	Service connection naar de host (`mcp-code`)	GitHub App met een kortlevend installation token
Goedkeuring voor productie	Environment met approvers	Environment met required reviewers
Runners	Managed DevOps Pool (Agents voorbereiden)	Zie Runners
Repository-opzet	Repositories voorbereiden	Dezelfde pagina, de GitHub-secties

Vereisten voor de organization¶

Het platformteam heeft de organization-rollen CI/CD admin en App Manager nodig en moet repositories kunnen aanmaken. Zie Vereisten en de GitHub-controles daar.

GitHub App voor de workflows¶

De workflows gebruiken geen personal access tokens. Ze maken een kortlevend installation token aan voor een GitHub App (actions/create-github-app-token) en geven dat door aan Terraform (TF_VAR_github_token).

Maak een GitHub App aan in de organization, of hergebruik er een. Geef hem een naam en omschrijving die aangeven dat hij door de platform-workflows wordt gebruikt.
Repository-rechten: read-toegang tot code en metadata, read and write-toegang tot workflows.
Sla de App ID op als organization-variabele cloud_platform_gh_app_id en de private key als organization-secret cloud_platform_gh_app_private_key (Pipelines).
Installeer de app in de organization met Only select repositories en selecteer alleen de coderepositories.
Bewaar een kopie van de private key in de secret store van het platformteam, samen met de naam en ID van de app.

Gebruiken spokes de GitHub-extensie, dan heeft de app een grotere set rechten nodig (Spoke-integraties voorbereiden). Worden Terraform-modules gedownload van een GitHub Enterprise-host, zie dan Toegang tot modulebronnen.

Dit is een andere app dan degene die de coderepository synchroniseert (Repositories voorbereiden). Je mag ze combineren als je securityregels dat toestaan, maar aparte apps houden de rechten klein.

Als mcp.json een GitHub-sectie heeft (AppId, AppInstallationId, AppPrivateKeySecretName), verwijst die naar de GitHub App die de self-hosted runners registreert (Config).

Federated credentials¶

Met federated credentials logt de workflow bij Azure in zonder opgeslagen secret. Voeg drie credentials toe aan de deployment service principal (Microsoft Entra ID, App registrations, de app, Certificates & secrets, Federated credentials, Add credential, scenario GitHub Actions deploying Azure resources) voor elke configuratierepository:

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. Voor GitHub.com is dat https://token.actions.githubusercontent.com. Voor GitHub Enterprise op een eigen domein (<domain>.ghe.com) is dat https://token.actions.<domain>.ghe.com. De namen van de organization en de repository zijn die uit de repository-URL.
Tijdens de implementatie, als de default branch initial is, maak je de branch-credential voor initial aan. Wijzig die naar main als de implementatie klaar is (Repositories voorbereiden).
Zet de client ID van de service principal in Azure.TerraformState.Hub.ServicePrincipalId (en .Spoke.) in mcp.json.

Secrets in oudere workflows¶

Oudere entry-workflows (main.yaml) lezen deze repository-secrets in plaats van mcp.json:

Secret	Waarde
`AZURE_CLIENT_ID`	Client ID van de service principal
`AZURE_TENANT_ID`	Tenant-ID
`AZURE_SUBSCRIPTION_ID`	Management subscription van de platformomgeving
`AZURE_RG_NAME`, `AZURE_SA_NAME`	Resource group en storage account van de Terraform state
`AZURE_SA_CONTAINER_NAME`	State container (voor spokes wordt een andere container gebruikt)
`AZURE_SA_LOG_CONTAINER_NAME`	Container voor deployment-logs

Environments¶

Maak de environments canary en prod aan in elke configuratierepository, plus approval-required als je de Approve*-modi gebruikt (Pipelines). Voor prod en approval-required:

required reviewers: de approver-groep, die leestoegang tot de repositories moet hebben,
Prevent self-review aan,
Allow administrators to bypass configured protection rules uit.

Zonder reviewers op approval-required gaat de goedkeuringsstap door zonder te wachten.

Runners¶

Huidige aanpak¶

De workflows infrastructure en container van het platform rollen de job runners uit, zoals bij Azure DevOps (Agents voorbereiden). De registratie van de runners gebruikt de GitHub App in mcp.json. De deployment van de hub draait op die runners.

Oudere aanpak: GitHub-hosted runners met virtual network-integratie¶

Eerdere versies rolden de hub in twee fasen uit met een ghrunners layer. Die layer maakt geen deel meer uit van de huidige hub pipeline; deze sectie is voor tenants die nog de oudere workflows draaien.

Fase 1, standaardrunners. De eerste layers (foundation, connectivity, ghrunners) draaien op een standaard GitHub-hosted runner group (een runner op de huidige Ubuntu image, bijvoorbeeld 2 cores, 8 GB, 75 GB schijf), omdat er nog geen netwerk bestaat. Laat defaultRunnerGroup in .github/workflows/main.yaml naar die groep wijzen.
Fase 2, runners met virtual network-integratie. Zodra het netwerk bestaat, maak je runners aan die erin draaien:
1. Haal de database-ID van de organization of enterprise op:
```
gh auth login -s 'read:enterprise'
gh api graphql -f query='query($login: String!) { organization(login: $login) { login databaseId } }' -f login='<organization>'
```
  Voor een enterprise vraag je in plaats daarvan enterprise (slug: $slug) op. Voor een ghe.com-host voeg je --hostname <subdomain>.ghe.com toe. 2. Registreer in de connectivity-subscription de resource provider GitHub.Network, delegeer het runner-subnet aan GitHub.Network/networkSettings en maak de network settings-resource aan (type GitHub.Network/networkSettings, met de subnet-ID en de database-ID als businessId). Doe dit voor canary en voor prod. Gebruik een regio die door het netwerk van GitHub-hosted runners wordt ondersteund (het runbook gebruikte North Europe omdat West Europe toen niet werd ondersteund; controleer de actuele lijst). 3. Maak in de organization-instellingen, Hosted compute networking, voor elke platformomgeving een network configuration aan met de resource-ID van de network settings. Als de optie is uitgeschakeld, moet de enterprise owner hem inschakelen. Geeft het formulier een JSON-fout, wacht dan een paar minuten en probeer opnieuw. 4. Maak per omgeving een runner group aan (bijvoorbeeld lz-canary en lz-prod) met die network configuration en toegang voor de vier repositories, en in elke groep een GitHub-hosted runner. Wacht tot de runnerstatus Ready is. 3. Zet defaultRunnerGroup in main.yaml om naar de nieuwe groep en draai dan de resterende layers in volgorde: firewall, identity, management, postdeployment. 4. Voeg firewallregels toe zodat de runners bij alles kunnen wat ze nodig hebben, zoals in Netwerktoegang van de agents.

Zie ook Het platform uitrollen.