Zum Inhalt

Die Plattform (hub) deployen

Diese Seite beschreibt das erste Deployment des hub: zuerst canary, dann prod. Sie setzt voraus, dass die Vorbereitungsphase abgeschlossen ist (Identität, Repositories, State-Speicher, Job runners und das mcp-Image). Die technische Reihenfolge steht im Deploy-Ablauf der Plattform, die layers unter Deployment-Layer.

Bevor du anfängst

  • [ ] Voraussetzungen geprüft, Identität eingerichtet
  • [ ] Repositories erstellt; die Konfiguration liegt auf dem Branch initial
  • [ ] State-Storage-Account sowie hub- und spoke-State-Container existieren (Agents vorbereiten)
  • [ ] infrastructure und container sind für canary (und später für prod) erfolgreich gelaufen
  • [ ] Der IP-Plan ist final
  • [ ] PIM ist für den Engineer aktiviert, der das Deployment ausführt

1. Die Konfiguration für canary füllen

Im Konfigurations-Repository, auf dem Branch initial:

  1. Setze environments/canary/mcp.json (Konfiguration): Tenant, State-Backends, Job runner, DevOps- Organisation oder GitHub App, IDs der Service Principals, SpokeCommon.tenantinfo.
  2. Setze global.auto.tfvars (Regionen, Namen, Subscription-IDs) sowie die tfvars für Region und layer, anhand des Mappings.
  3. Durchsuche das gesamte Repository nach Werten des Templates (Kundenname, Subscription-IDs und Ressourcen-IDs). Policy- Dateien enthalten Azure-Ressourcen-IDs.
  4. Prüfe jeden Ordner firewall_rule_configuration: Mindestens eine JSON-Datei muss existieren, auch wenn die Plattform noch keine Regeln hat.
  5. Prüfe, dass die DNS-Server-Adresse der firewall policy mit der Adresse des Inbound-Endpunkts des DNS Private Resolvers derselben Plattform-Umgebung übereinstimmt.
  6. Prüfe in den Entry-pipelines die gepinnte Version, den Agent Pool, die Service Connections oder Environments und welche mcp.json jeder Entry anspricht.

Prüfe mode und whatIf in den Entry-pipelines. Das Referenz-Konfigurations-Repository wendet den hub ohne Genehmigung an (Pipelines). Nutze für den ersten Lauf Plan.

2. Resource Provider registrieren

Stelle sicher, dass alle Resource Provider, die die Plattform braucht, in jeder Plattform-Subscription registriert sind. Wenn deine Version das Skript scripts/register-az-providers.ps1 im Code-Repository enthält, führe es aus, nachdem du dich mit dem Tenant verbunden hast:

Connect-AzAccount -TenantId <tenant-id>

Andernfalls registriere die Provider, die in den Fehlern des ersten Plans genannt werden. Dieser Schritt gehört auch zu den Voraussetzungen.

3. Den hub in canary planen und anwenden

Führe hub vom Branch initial für die Plattform-Umgebung canary aus, zuerst im Modus Plan.

  1. Lies den Plan jedes layers. Bei einem ersten Deployment wird alles erstellt. Prüfe Namen, Regionen, Adressbereiche und die Feature-Schalter gegen das Design. Ein Plan, der bei einem ersten Deployment irgendetwas zerstören will, bedeutet einen falschen Pfad oder einen falschen Wert. Stoppe und finde heraus, warum (Konfiguration: Ein falscher Pfad löscht Ressourcen).
  2. Führe hub erneut im Modus Apply (oder ApproveModifications) aus.
  3. Die pipeline führt die layers in der festen Reihenfolge aus: foundation und connectivity in der primären Region, dann in den anderen Regionen, dann firewall, identity und management in allen Regionen, und postdeployment in der primären Region (Deploy-Ablauf).
  4. Wenn die pipeline fertig ist, führe sie noch einmal aus. Ein zweiter Plan muss keine Änderungen zeigen. Abweichungen, die immer wieder auftauchen (zum Beispiel Attribute von Policies oder Application Gateway), stehen unter Bekannte Probleme.

Warum die Reihenfolge bei einem ersten Deployment wichtig ist

Die layers hängen voneinander ab, zum Beispiel vom virtuellen Netzwerk. Die pipeline kümmert sich um die Reihenfolge. Wenn du layers oder Regionen von Hand ausführst, halte sie ein: Bei einem sauberen Deployment zuerst foundation und connectivity in der primären Region, dann in den anderen Regionen, erst danach firewall, identity und management, und postdeployment zuletzt. (Ältere Runbooks führten zuerst foundation in allen Regionen aus und dann connectivity, primäre Region zuerst.)

Vollständige oder teilweise Läufe

Was sich geändert hat Ausführen
Ein neuer layer, eine globale Einstellung, mehrere layers oder eine neue Plattform-Version Der vollständige hub (alle layers, alle Regionen)
Ein layer Nur dieser layer, wo deine Entry-pipeline das anbietet, oder der vollständige hub, und prüfe, dass die anderen layers keine Änderungen planen
Regionsspezifische Einstellungen Nur diese Region, wo deine Entry-pipeline das anbietet

Ältere Entry-pipelines haben die Laufzeitparameter Environment, Region und Layer, jeweils mit dem Wert all. Prüfe, welche Parameter deine Entry-pipelines anbieten (Pipelines).

4. Die Agents durch die firewall lassen

Nachdem der hub existiert, erreichen die Job runners Azure und die Paketquellen über die hub-firewall. Wenn du deployment_agents_private_network_range setzt, erstellt die Plattform die Rule Collection Group dafür. Andernfalls füge die Regeln von Hand für das Agent-Subnetz hinzu (siehe Netzwerkzugriff der Agents). In älteren layer-weisen Läufen laufen die ersten layers auf temporären Runnern und der Rest erst, nachdem diese Regeln existieren.

5. Prod aus canary vorbereiten

Wenn canary funktioniert, kopiere die canary-Konfiguration nach prod und ändere die Werte, die abweichen müssen:

  • jeden Umgebungsnamen und Kurznamen (canary / cnry) auf den prod-Namen,
  • alle Subscription-IDs und management-group-IDs,
  • alle IP-Adressen und Bereiche,
  • die Service Connection oder die Zugangsdaten, das State-Backend und den Agent Pool in mcp.json,
  • Genehmigungen und Branch-Schutz (diese gelten nur für prod, siehe Repositories vorbereiten).

Führe hub für prod im Modus Plan aus, lies alle Pläne und wende dann an. Produktion braucht immer eine Genehmigung: Nutze einen Approve*- Modus oder ein Environment mit erforderlichen Reviewern.

6. Mergen und aufräumen

  1. Erstelle einen pull request von initial nach main, lass ihn prüfen und merge ihn. Setze den Default-Branch (GitHub) zurück auf main und aktualisiere die federated credential für den Branch.
  2. Führe hub noch einmal von main für canary und prod aus und bestätige, dass keine Änderungen geplant werden.
  3. Schalte die Schutzmaßnahmen für main und für prod ein (Repositories vorbereiten).
  4. Deploye einen Test-spoke: Das Spoke Canvas deployen.

Ältere layer-weise Läufe

pipelines vor der pipeline hub (eine einzelne pipelines/main.yaml oder .github/workflows/main.yaml, mit dem Plattform- Code als Repository-Ressource xms-landing-zone-core) liefen einen layer nach dem anderen. Die gleiche Vorbereitung gilt. In diesen Versionen:

  • Die pipeline zeigte auf den Pool (AzureDevOpsAgents_Prod oder _Canary im älteren Agent-Setup) und las den State- Speicherort aus einer Variable Group (Service Connection, Container, Resource Group, Storage Account, Terraform-Version und Subscription des State).
  • Für das erste Deployment führtest du in canary aus: den foundation-layer für alle Regionen, den connectivity-layer (Hauptregion, dann die anderen Regionen), den vollständigen canary-Lauf für alle Regionen und (auf GitHub) den layer ghrunners. Dann stelltest du die pipeline auf die selbst gehosteten oder netzwerkintegrierten Runner um und führtest firewall, identity, management und postdeployment aus, danach noch einmal alles.
  • Prod folgte derselben Reihenfolge, nachdem die canary-Konfiguration kopiert und angepasst war.
  • Updates liefen layer für layer in der Reihenfolge foundation, connectivity, identity, management, firewall, postdeployment (auf GitHub zuerst ghrunners), für canary und dann prod, und endeten mit einem vollständigen Lauf von main.

Wie du einen Tenant mit so einer Version aktualisierst, steht unter Was zu tun ist, wenn eine neue Version veröffentlicht wird (Legacy-Hinweis) und Von einer älteren Plattform-Version migrieren.