Ein Demo- oder Test-Deployment aufräumen¶

Demo-, Test- und Trainingsumgebungen sowie gescheiterte Implementierungsversuche müssen wieder entfernt werden, damit sie nicht Geld kosten oder Objekte im Tenant zurücklassen. Diese Seite beschreibt, wie du eine Plattform-Umgebung abbaust und wie du sie von Grund auf neu aufbaust.

Nur für Umgebungen, die du verlieren kannst

Ein destroy entfernt Netzwerk, Firewall, Policies und management groups des hub sowie die spokes mit ihren Key Vaults und Storage-Accounts. Verwende ihn nur auf einer Demo- oder Test-Plattform-Umgebung oder auf der canary-Umgebung eines Kunden, der zugestimmt hat. Führe ihn niemals gegen eine produktive Plattform-Umgebung aus. Prüfe vor dem Start die mcp.json, auf die die destroy-pipeline zeigt.

Reihenfolge: erst die spokes, dann der hub¶

Entferne die spokes mit der spoke-destroy-pipeline, eine spoke-Datei nach der anderen (spokeGlob auf diese Datei gesetzt). Verwende dieselbe mcp.json wie beim spoke-Lauf, der sie erstellt hat. Der destroy sollte die spoke-Umgebungen in der umgekehrten Reihenfolge des Deployments ausführen (prd, acc, tst, dev). Prüfe, dass deine Kopie der Entry-Datei das tut, denn ältere Kopien liefen zuerst mit dev (Bekannte Probleme). Details und die Warnung vor Datenverlust: spoke löschen. Die pipeline kündigt die subscription nicht und setzt ihre Tags und ihren Namen nicht zurück.
Entferne den hub mit der hub-destroy-pipeline. Sie führt die layers in umgekehrter Reihenfolge aus: postdeployment, dann firewall, identity und management, dann connectivity, dann foundation (Deployment-layers), jeweils pro Region. Im Referenz-Konfigurations-Repository zielt sie nur auf canary.
Prüfe, was übrig ist (siehe unten).
Entferne die Job runners und den state nur, wenn die ganze Umgebung verschwindet: die resource group der runner, der Terraform-state-Storage-Account, die Service Principals und die Objekte in Azure DevOps oder GitHub.

Prüfe die Entry-Dateien, bevor du sie ausführst: mode: Apply wendet den destroy ohne Genehmigungsstopp an, und whatIf: true plant ihn nur. Führe ihn einmal mit whatIf: true aus, lies den destroy-Plan und führe ihn dann mit whatIf: false erneut aus (Pipelines).

Schneide nicht deine eigenen Agents ab

Wenn das virtuelle Netzwerk der runner mit internet_security_enabled = true an den hub angebunden ist, entfernt der destroy des connectivity-layers die Route der Agents zu Azure DevOps oder GitHub, und die nächsten Schritte können nicht laufen. Vermeide das, indem du das runner-Netzwerk mit internet_security_enabled = false anbindest, oder führe die letzten layers von einem anderen runner aus (siehe Netzwerkzugriff der Agents).

Was nach einem destroy übrig bleiben kann¶

Bleibt übrig	Warum	Aktion
Subscriptions, mit ihren Tags und Namen	Die pipeline kündigt subscriptions nie	Von Hand außer Betrieb nehmen oder weiterverwenden (spoke löschen)
Soft-deleted Key Vaults	Soft delete und purge protection behalten sie. Ein Key Vault, der mit demselben Namen neu erstellt wird, wird mit seinen alten Secrets wiederhergestellt (`recover_soft_deleted_key_vaults = true`).	Purge sie, wenn du einen sauberen Neustart willst (Bekannte Probleme)
Custom-Policy-Definitionen und -Initiativen an der management group	Ältere Cleanup-pipelines entfernten die Policy-(Set-)Definitionen ausdrücklich, bevor der foundation-layer zerstört wurde	Liste die benutzerdefinierten Definitionen und Set-Definitionen an der Plattform-management-group auf und entferne Reste
Management groups und Rollenzuweisungen	Ein fehlgeschlagener oder teilweiser destroy kann sie zurücklassen	Prüfe den Baum der management groups und das IAM der Plattform-management-group
Entra-ID-Gruppen und Service Principals der spokes	Von der spoke-pipeline in der Administrative Unit erstellt	Prüfe, dass der spoke-destroy sie entfernt hat
Terraform-state-Dateien	Werden vom destroy nicht gelöscht	Lösche die Blobs der entfernten layers und spokes, wenn du sie mit anderen Werten neu erstellst
Resource groups der Job runners	Von `infrastructure` deployt, nicht vom hub	Entferne sie, wenn die ganze Umgebung verschwindet

Geplantes Aufräumen einer Demo-Umgebung¶

Eine Demo-Umgebung, die nur gelegentlich genutzt wird, sollte automatisch entfernt werden. Eine ältere Cleanup-pipeline tat das für die canary-Plattform-Umgebung nach Zeitplan (jede Nacht): Pro Region zerstörte sie die layers postdeployment, firewall, identity, management und connectivity, entfernte die Policy-(Set-)Definitionen und zerstörte den foundation-layer. Ihre einzige umgebungsspezifische Einstellung war die ID der Plattform-management-group.

Dasselbe kannst du mit einem geplanten Lauf von hub-destroy für die Demo-Plattform-Umgebung bauen. Halte dabei zwei Regeln ein:

Plane es nur auf einer Umgebung, die nichts enthält, was du behalten willst.
Führe das Aufräumen von Hand aus, sobald du eine Demo oder einen Test beendest, damit du nicht über Nacht für die ungenutzte Umgebung zahlst.

Wieder von Grund auf deployen¶

Bei einem regulären Kunden findet ein sauberes (erstmaliges) Deployment einmal statt. Bei einer Demo-Umgebung, die du regelmäßig zerstörst, passiert es jedes Mal. Ein sauberes Deployment braucht die layers und Regionen in einer bestimmten Reihenfolge, weil sie bei Ressourcen wie dem virtuellen Netzwerk voneinander abhängen: Die hub-pipeline übernimmt das (Die Plattform deployen). Verwende den vollständigen hub-Lauf, nicht einzelne layers.

Vor dem erneuten Lauf:

[ ] Die Job runners und das mcp-Image existieren noch (oder führe zuerst infrastructure und container aus)
[ ] Der state-Storage-Account und der spoke-state-Container existieren noch
[ ] Übrig gebliebene Policy-Definitionen und soft-deleted Key Vaults sind wie oben aufgeräumt
[ ] Die subscriptions sind wieder unter der Plattform-management-group (ein neuer Baum von management groups wird vom foundation-layer erstellt)
[ ] Die Konfiguration passt noch zu deinem Ziel. Entferne die spoke-Dateien der spokes, die du zerstört hast, sonst erstellt der nächste spoke-Lauf sie neu.