De spoke pipeline voorbereiden¶

Deze pagina behandelt wat je voorbereidt zodat spokes vanuit een pipeline kunnen worden gedeployed: de identiteit die spokes uitrolt, toegang tot de code, de service connections en de pipeline zelf. Ze beschrijft de aparte spoke canvas-deployment: een spoke-coderepository, een spoke-configuratierepository of -map, en een eigen pipeline. Dit is de indeling van eerdere platformversies, en sommige implementaties gebruiken haar nog. In de huidige indeling roept de entry pipeline spoke in de configuratierepository de coderepository aan, en de meeste stappen hier worden al gedekt door Identiteit voorbereiden en Repositories voorbereiden. Gebruik de tabel om te zien wat van toepassing is.

Onderwerp	Huidige indeling	Aparte spoke canvas-deployment
Spoke-identiteit en rechten	Identiteit voorbereiden	Spoke deployment identity
Toegang tot de code	Eén coderepository, gepind in de entry pipeline	Waar de code staat
Service connections	Identiteit voorbereiden	Service connections
Pipeline	Entry pipeline `spoke` (Pipelines)	De pipeline aanmaken
Spoke-instellingen	`mcp.json` `SpokeCommon`	`common.tf` (Spoke common settings)

Voordat je begint, moeten de groepen, de administrative unit en de management group uit Identiteit voorbereiden bestaan. Wie wat doet, hangt af van het beheermodel.

Spoke deployment identity¶

Maak een service principal die speciaal is voor spoke-deployment. Een speciale identiteit kan worden beperkt tot wat spokes nodig hebben. Maak er twee met gelijke rechten: een voor de canary-platformomgeving en een voor productie.

Waar	Vereiste
Management group	Owner op de `landingzone` management group van zijn omgeving. De canary-identiteit krijgt die van canary, de productie-identiteit die van productie.
Microsoft Graph, application permissions	De lijst in Identiteit voorbereiden, met admin consent
Administrative unit	Groups Administrator op de administrative unit die de spoke-groepen bevat

De lijst met Graph-permissies in de documentatie van de codeversie die je pint, is leidend.

Waar de code staat¶

De Terraform van de spoke-deployment is een coderepository. Er zijn twee manieren om de pipeline toegang daartoe te geven. De eerste is de standaard.

Optie 1: de code blijft bij het platformteam (standaard)¶

De pipeline leest de code uit de repository van het platformteam via een service connection. Dit heb je alleen nodig als de parameters-repository (die met de spoke-bestanden) niet in dezelfde organisatie staat als de code.

Meld je aan bij de Azure DevOps-organisatie die de parameters bevat en open het project.
Project settings, Service connections, New service connection.
Kies Azure Repos/Team Foundation Server, daarna Token based authentication.
Vul in:
- Connection URL: de URL van de coderepository <code repository URL>.
- Personal access token: een token van de organisatie van het platformteam met leestoegang tot die repository.
Kies Verify, geef de connection een naam en beschrijving en kies Verify and save.

Behandel het token als een secret

Een personal access token verloopt en hoort bij een persoon. Spreek af wie het wanneer vernieuwt, en zet de vervaldatum in de onderhoudskalender (Secret watcher).

Optie 2: de code wordt gehost in de organisatie van de klant¶

Gebruik dit als de klant de code in zijn eigen organisatie wil.

Ga in het project van de klant naar Repos, New repository. Geef hem de naam die de pipeline verwacht (het voorbeeld gebruikt spokedeployment-tf), type Git.
Clone hem, kopieer de inhoud van de coderepository van het platformteam erin en push.
Controleer dat de push is geslaagd.

Daarna ben jij verantwoordelijk voor het bijwerken van die kopie wanneer een nieuwe versie wordt gereleased (Versiebeheer). Houd hem alleen-lezen voor iedereen behalve de identiteit die hem bijwerkt (Repositories voorbereiden).

Service connections voor de spoke-identiteiten¶

Maak voor elk van de twee identiteiten een Azure Resource Manager service connection aan. Herhaal de stappen voor canary en productie.

Ga in het project naar Project settings, Service connections, New service connection, Azure Resource Manager.
Kies Service principal (manual) en Management Group als scope.

Vul in:

Veld	Waarde
Management group ID and name	De `landingzone` management group van deze omgeving: onder de canary-boom voor de canary-identiteit, onder de productieboom voor de productie-identiteit.
Service principal ID	Client-ID van de service principal
Service principal key	Client secret
Tenant ID	De tenant van de klant
Service connection name	Bijvoorbeeld `SpokeDeployment_Prd` en `SpokeDeployment_Canary`

Kies Verify, daarna Save.

Haal het secret uit je secret store. Geef de voorkeur aan workload identity federation waar je versie dat ondersteunt.

De pipeline aanmaken¶

Ga in het project naar Pipelines, New pipeline (of Create pipeline als het de eerste is).
Where is your code: Azure Repos Git. Selecteer de repository met de pipelinecode.
Configure your pipeline: Existing Azure Pipelines YAML file. Branch main. Pad: het spoke-pipelinebestand van jouw indeling (het voorbeeld gebruikt /pipelines/SpokeDeployment.yaml).
Open het menu Run en kies Save. Draai hem nog niet.
Open in de pipelinelijst (All) het menu van de pipeline, Rename/move, en geef hem een duidelijke naam, bijvoorbeeld Landing Zone - Spoke deployment.

De pipeline start automatisch wanneer een pull request in main wordt gemerged, zoals beschreven in Nieuwe spoke.

Parameters in een andere repository¶

De spoke-bestanden kunnen in een andere repository staan dan de pipeline, bijvoorbeeld op GitHub. Voeg de repository toe als resource en geef de naam ervan door aan de stage-templates:

resources:
  repositories:
    - repository: spoke-canvas-params
      endpoint: <GitHub service connection>
      type: github
      name: <organization>/<repository>
      ref: main

stages:
  - template: /pipelines/templates/stages/prepare-matrix.yaml@<code repository resource>
    parameters:
      checkout: spoke-canvas-params
      stageId: prepStage
  - template: /pipelines/templates/stages/deploy-matrix.yaml@<code repository resource>
    parameters:
      checkout: spoke-canvas-params
      stageId: deployStage

<GitHub service connection> is een GitHub service connection die je aan het Azure DevOps-project toevoegt. Templatepaden en resourcenamen zijn die van jouw versie; het voorbeeld toont het idee, niet het exacte bestand. Kopieer het niet zonder het te controleren tegen de entry pipeline die je hebt.

Subscriptions aanmaken¶

De spoke-deployment heeft een bestaande subscription nodig. In de aparte indeling kan een tweede pipeline die aanmaken, maar het aanmaken van subscriptions was in de brondocumentatie niet definitief en vraagt billinginformatie van een CSP-account. Lees eerst Nieuwe spoke. Gebruik je toch een subscription-pipeline:

Maak hem op dezelfde manier aan als hierboven, met het bestand van jouw versie (het voorbeeld gebruikt /pipelines/create-subscription.yaml) en een naam zoals Landing Zone - Create Spoke Subscription.
Draai hem met de workload short name, de omgeving en de management group.
Open de run, de Terraform apply-stap, en lees subscription_id uit de output. Je hebt die nodig in het spoke-bestand.

Controleren¶

[ ] Er bestaan twee spoke-identiteiten (canary en productie) met Owner op hun landingzone management group
[ ] Graph-permissies hebben consent en de rol op de administrative unit is toegewezen
[ ] De pipeline kan de code lezen (service connection geverifieerd, of de kopie bestaat)
[ ] Er bestaan twee Azure Resource Manager service connections en ze verifiëren
[ ] De pipeline bestaat en is opgeslagen
[ ] Maakt de spoke Azure DevOps- of GitHub-resources aan: Spoke-integraties voorbereiden

Volgende: De spoke canvas deployen.