Die spoke-pipeline vorbereiten¶

Diese Seite behandelt, was du vorbereitest, damit spokes aus einer pipeline deployt werden können: die Identität, die spokes deployt, den Zugriff auf den Code, die service connections und die pipeline selbst. Sie beschreibt das separate spoke-canvas-Deployment: ein spoke-Code-Repository, ein spoke-Konfigurations-Repository oder -Ordner und eine eigene pipeline. Das ist das Layout früherer Plattformversionen, und manche Implementierungen nutzen es noch. Im aktuellen Layout ruft die Entry-pipeline spoke im Konfigurations-Repository das Code-Repository auf, und die meisten Schritte hier sind bereits durch Identität vorbereiten und Die Repositories vorbereiten abgedeckt. Anhand der Tabelle siehst du, was für dich gilt.

Thema	Aktuelles Layout	Separates spoke-canvas-Deployment
Spoke-Identität und Berechtigungen	Identität vorbereiten	Spoke-Deployment-Identität
Code-Zugriff	Ein Code-Repository, in der Entry-pipeline fixiert	Wo der Code liegt
Service connections	Identität vorbereiten	Service connections
Pipeline	Entry-pipeline `spoke` (Pipelines)	Die pipeline erstellen
Spoke-Einstellungen	`mcp.json` `SpokeCommon`	`common.tf` (Gemeinsame Spoke-Einstellungen)

Bevor du anfängst, müssen die Gruppen, die Administrative Unit und die management group aus Identität vorbereiten existieren. Wer was macht, hängt vom Betriebsmodell ab.

Spoke-Deployment-Identität¶

Erstelle einen Service Principal, der ausschließlich für das spoke-Deployment gedacht ist. Eine dedizierte Identität lässt sich auf das begrenzen, was spokes brauchen. Erstelle zwei mit gleichen Rechten: eine für die canary-Plattformumgebung und eine für die Produktion.

Wo	Anforderung
Management group	Owner auf der management group `landingzone` ihrer Umgebung. Die canary-Identität bekommt die von canary, die Produktionsidentität die der Produktion.
Microsoft Graph, Application permissions	Die Liste unter Identität vorbereiten, mit Admin Consent
Administrative Unit	Groups Administrator auf der Administrative Unit, die die spoke-Gruppen enthält

Maßgeblich ist die Liste der Graph-Berechtigungen in der Dokumentation der Code-Version, die du fixiert hast.

Wo der Code liegt¶

Das Terraform des spoke-Deployments ist ein Code-Repository. Es gibt zwei Wege, der pipeline Zugriff darauf zu geben. Der erste ist der Standard.

Option 1: Der Code bleibt beim Plattform-Team (Standard)¶

Die pipeline liest den Code über eine service connection aus dem Repository des Plattform-Teams. Das brauchst du nur, wenn das Parameter-Repository (das mit den spoke-Dateien) nicht in derselben Organisation liegt wie der Code.

Melde dich bei der Azure-DevOps-Organisation an, die die Parameter enthält, und öffne das Projekt.
Project settings, Service connections, New service connection.
Wähle Azure Repos/Team Foundation Server, dann Token based authentication.
Fülle aus:
- Connection URL: die URL des Code-Repositorys <code repository URL>.
- Personal access token: ein Token aus der Organisation des Plattform-Teams mit Lesezugriff auf dieses Repository.
Wähle Verify, gib der Verbindung einen Namen und eine Beschreibung und wähle dann Verify and save.

Behandle das Token als Secret

Ein Personal Access Token läuft ab und gehört einer Person. Vereinbare, wer es wann erneuert, und trage das Ablaufdatum in den Wartungskalender ein (Secret Watcher).

Option 2: Der Code liegt in der Organisation des Kunden¶

Nutze das, wenn der Kunde den Code in seiner eigenen Organisation haben will.

Im Projekt des Kunden: Repos, New repository. Benenne es so, wie die pipeline es erwartet (im Beispiel spokedeployment-tf), Typ Git.
Klone es, kopiere den Inhalt des Code-Repositorys des Plattform-Teams hinein und pushe.
Prüfe, ob der Push erfolgreich war.

Du bist dann dafür verantwortlich, diese Kopie zu aktualisieren, wenn eine neue Version veröffentlicht wird (Versionierung). Halte sie für alle schreibgeschützt außer für die Identität, die sie aktualisiert (Die Repositories vorbereiten).

Service connections für die spoke-Identitäten¶

Erstelle für jede der beiden Identitäten eine Azure-Resource-Manager-service-connection. Wiederhole die Schritte für canary und Produktion.

Im Projekt: Project settings, Service connections, New service connection, Azure Resource Manager.
Wähle Service principal (manual) und Management Group als Scope.

Fülle aus:

Feld	Wert
Management group ID and name	Die management group `landingzone` dieser Umgebung: unter dem canary-Baum für die canary-Identität, unter dem Produktionsbaum für die Produktionsidentität.
Service principal ID	Client-ID des Service Principals
Service principal key	Client Secret
Tenant ID	Der Tenant des Kunden
Service connection name	Zum Beispiel `SpokeDeployment_Prd` und `SpokeDeployment_Canary`

Wähle Verify, dann Save.

Nimm das Secret aus deinem Secret Store. Bevorzuge Workload Identity Federation, wo deine Version sie unterstützt.

Die pipeline erstellen¶

Im Projekt: Pipelines, New pipeline (oder Create pipeline, wenn es die erste ist).
Where is your code: Azure Repos Git. Wähle das Repository, das den pipeline-Code enthält.
Configure your pipeline: Existing Azure Pipelines YAML file. Branch main. Pfad: die spoke-pipeline-Datei deines Layouts (im Beispiel /pipelines/SpokeDeployment.yaml).
Öffne das Menü Run und wähle Save. Führe sie noch nicht aus.
In der pipeline-Liste (All) öffnest du das Menü der pipeline, Rename/move, und gibst ihr einen klaren Namen, zum Beispiel Landing Zone - Spoke deployment.

Die pipeline startet automatisch, wenn ein pull request nach main gemerged wird, wie unter Neuer Spoke beschrieben.

Parameter in einem anderen Repository¶

Die spoke-Dateien können in einem anderen Repository liegen als die pipeline, zum Beispiel auf GitHub. Füge das Repository als Ressource hinzu und übergib seinen Namen an die 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> ist eine GitHub-service-connection, die du dem Azure-DevOps-Projekt hinzufügst. Template-Pfade und Ressourcennamen sind die deiner Version; das Beispiel zeigt die Idee, nicht die exakte Datei. Kopiere es nicht, ohne es mit der Entry-pipeline abzugleichen, die du hast.

Subscriptions erstellen¶

Das spoke-Deployment braucht eine bestehende subscription. Im separaten Layout kann eine zweite pipeline sie erstellen, aber die Subscription-Erstellung war in der Quelldokumentation nicht final und braucht Billing-Informationen eines CSP-Accounts. Lies zuerst Neuer Spoke. Wenn du eine Subscription-pipeline nutzt:

Erstelle sie wie oben, mit der Datei deiner Version (im Beispiel /pipelines/create-subscription.yaml) und einem Namen wie Landing Zone - Create Spoke Subscription.
Führe sie mit dem Workload-Kurznamen, der Umgebung und der management group aus.
Öffne den Lauf, den Terraform-Apply-Schritt, und lies subscription_id aus dem Output. Du brauchst sie in der spoke-Datei.

Prüfen¶

[ ] Zwei spoke-Identitäten existieren (canary und Produktion), mit Owner auf ihrer management group landingzone
[ ] Graph-Berechtigungen sind consented, und die Rolle auf der Administrative Unit ist zugewiesen
[ ] Die pipeline kann den Code lesen (service connection verifiziert, oder die Kopie existiert)
[ ] Zwei Azure-Resource-Manager-service-connections existieren und lassen sich verifizieren
[ ] Die pipeline existiert und ist gespeichert
[ ] Wenn der spoke Azure-DevOps- oder GitHub-Ressourcen erstellt: Spoke-Integrationen vorbereiten

Weiter: Das spoke canvas deployen.