Zum Inhalt

Das Spoke Canvas deployen

Deploye nach dem hub einen Test-spoke, um zu beweisen, dass die spoke-pipeline, die spoke-Identität und die Verbindung zum hub funktionieren. Den Test-spoke zeigst du auch bei der Übergabe. Echte spokes folgen der Standardänderung Neuer Spoke; diese Seite behandelt, was beim ersten Mal anders ist.

Bevor du anfängst

Hintergrund dazu, was das Deployment erstellt und welche Berechtigungen es braucht: Spoke canvas. Warum subscriptions nicht aus einem Pool genommen werden: Subscription provisioning.

  • [ ] Der hub ist in der Plattform-Umgebung deployt, die du ansprichst (Die Plattform deployen)
  • [ ] Die spoke-Identität hat ihre Berechtigungen und der Graph Admin Consent wurde erteilt (Identität vorbereiten)
  • [ ] SpokeCommon.tenantinfo in mcp.json enthält die ID der Administrative Unit, die Präfixe für Gruppen und Service Principals, das Namenstemplate für Subscriptions und den Rotationszeitraum für Secrets. Beim separaten spoke-canvas-Deployment stehen die gemeinsamen Einstellungen in common.tf (Gemeinsame Spoke-Einstellungen)
  • [ ] Wenn du die separate spoke-canvas-pipeline nutzt: Die spoke-pipeline vorbereiten ist erledigt
  • [ ] Wenn der Test-spoke Azure-DevOps- oder GitHub-Ressourcen erstellt: Spoke-Integrationen vorbereiten ist erledigt
  • [ ] Wenn du IPAM-Pools nutzt: Die Pools stehen in den gemeinsamen Einstellungen (Spoke-JSON-Referenz)
  • [ ] Der spoke-State-Container existiert (Agents vorbereiten)
  • [ ] Eine leere (oder Test-) Subscription steht für den spoke bereit. Die pipeline kann ohne CSP- Billing-Account keine Subscriptions erstellen.
  • [ ] Die Team-Gruppe, die Zugriff bekommt, existiert in Entra ID (ProductTeamGroupNames)
  • [ ] Die management group für den spoke existiert in der management_group_structure des hub
  • [ ] Ein IP-Bereich für den spoke ist im IP-Plan reserviert

Schritte

  1. Erstelle die spoke-Datei in <env-folder>/spokes/<team>/, zum Beispiel canvas_<workload>_dev.json. Starte mit dem Beispiel unter Neuer Spoke und der spoke-JSON-Referenz. Die Blöcke, die du füllst:

    Block Inhalt für den Test-spoke
    workloadShortName, environment Ein Kurzname (höchstens 6 Zeichen) und eine Nicht-Produktionsumgebung
    azureSubscriptionId, azureSubscriptionName, managementGroupId Die Test-Subscription, ihr Name und eine landing-zone-management-group
    tags Owner, Abteilung, workload, pii, Kostenstelle, Umgebung
    adInfo ProductTeamGroupNames und PIMGroupConfig (nopim, self-approve oder approval pro spoke-Gruppe)
    targetRegions Die primäre Region des hub (und weitere Regionen, wenn du sie testen willst)
    resourceconfiguration.network[] Ein virtuelles Netzwerk aus dem reservierten Bereich, mit einem Default-Subnetz, einer NSG pro Subnetz und peerHub: true

    Entferne die Beispiel-spoke-Dateien, die mit dem Template kamen, damit sie nicht laufen.

  2. Prüfe die Entry-pipeline spoke: gepinnte Version, Agent Pool, Service Connection (oder federated credential), mcp.json der richtigen Plattform-Umgebung, environments und mode/whatIf. Im Referenz-Konfigurations- Repository hat spoke.yaml whatIf: true und plant das Canvas daher nur (Pipelines).

  3. Erstelle das Genehmigungs-Environment für Produktions-spokes, falls du eines nutzt, mit Genehmigern und ohne Selbstgenehmigung (Repositories vorbereiten).
  4. Führe spoke aus mit spokeGlob auf die eine Test-spoke-Datei gesetzt, zuerst als Plan. Lies den Plan: Der erste Lauf erstellt die Resource Group, das Netzwerk, die hub-Verbindung, Gruppen, den Service Principal, Key Vault, Storage Account und Rollen- zuweisungen (Was erstellt wird).
  5. Wende an, führe dann erneut aus und bestätige, dass der zweite Plan keine Änderungen zeigt. Bekanntes Plan-Rauschen bei spokes steht unter Bekannte Probleme.
  6. Verifiziere mit der Liste unter Neuer Spoke: management group, Tags, virtuelles Netzwerk, hub-Verbindung, die vier spoke-Gruppen, PIM-Aktivierung durch ein Mitglied der Team-Gruppe.
  7. Merge die spoke-Datei per pull request nach main. Wenn du Build Validation im Konfigurations-Repository nutzt, laufen die spoke-Config-Tests auf diesem pull request.

Behalte den Test-spoke, bis die Validierung abgeschlossen ist. Danach behältst du ihn entweder als Beispiel für die Übergabe oder entfernst ihn mit Spoke löschen.

Häufige Probleme beim ersten Lauf

Symptom Ursache
Das Backend lässt sich nicht initialisieren Der spoke-State-Container existiert nicht, oder die Identität hat keine Blob-Data-Rolle auf dem Account
Das Erstellen von Gruppen oder PIM-Einstellungen scheitert mit einem Berechtigungsfehler Es fehlt die Graph-Berechtigung oder der Admin Consent, oder die Identität ist nicht Groups Administrator auf der Administrative Unit
Der Config Test lehnt die Datei ab Die managementGroupId steht nicht in der management-group-Struktur des hub, die environment steht nicht in den environments der pipeline, oder das JSON passt nicht zum Schema
Die Team-Gruppe wird nicht gefunden Die Gruppe in ProductTeamGroupNames existiert nicht in Entra ID (der Anzeigename muss übereinstimmen)
Die hub-Verbindung scheitert Der hub in dieser Region ist noch nicht deployt, oder der Adressbereich überschneidet sich mit einem anderen Netzwerk

Einen spoke später aktualisieren

Nach dem ersten spoke folgen Änderungen der Standardänderung Spoke ändern: ein Branch, eine Änderung der spoke-Datei, ein pull request, den jemand anderes prüft, und ein pipeline-Lauf für genau diese Datei. Manche Änderungen sind wegen Einschränkungen von Terraform oder Azure nicht möglich, zum Beispiel die Änderung eines Subnetzes, das virtuelle Maschinen nutzen.

Älteres Layout

In Versionen mit separaten spoke-Repositories sah dieselbe Arbeit so aus:

  • Die spoke-Datei lag im spoke-Konfigurations-Repository unter spokes/tfspokes/<workload>/canvas_<...>.json. Die ID der Administrative Unit wurde in common.tf gesetzt, und spokeschema.json enthielt das Schema.
  • Die pipeline hieß SpokeDeployment.yaml (Azure DevOps) oder der Workflow Spoke Deployment (GitHub), und eine separate pipeline verifizierte spoke-Dateien bei jedem pull request.
  • Die pipeline ist in Die spoke-pipeline vorbereiten beschrieben. Spoke-Dateien mussten canvas_<...>.json heißen und _prod_ oder _nonprod_ enthalten.
  • Eine Variable Group enthielt die Service Connection, die Tenant-ID, die Terraform-Version, den State-Storage-Account, die Resource Group und Subscription, den spoke-State-Container, den Log-Container und den Filter, der spoke-Dateien auswählt.
  • Auf GitHub musste das Repository-Secret für den Namen des State-Containers auf den spoke-State-Container geändert werden, und die spoke-Identität brauchte Storage Blob Data Contributor auf dem Storage Account.
  • Das Environment für Produktions-spoke-Deployments hatte Genehmiger, ohne Selbstgenehmigung.