Zum Inhalt

spoke löschen

Standardänderung: Löschen von workload/spokes/Application Landing Zone (spoke canvas)

Auswirkung: Alles, was das spoke canvas in der subscription und im Hub erstellt hat, wird zerstört, einschließlich des Netzwerks. Die subscription selbst wird nicht gekündigt. Ihre Tags und ihr Name werden nicht zurückgesetzt. Die Zuordnung zur management group kann ebenfalls entfernt werden (siehe Was zerstört wird).

Datenverlust. Dies zerstört die resource groups, den Key Vault und das Storage Account des spokes (prevent_deletion_if_contains_resources = false in spoke-canvas/deploy/spoke/providers.tf). Ressourcen, die das workload- Team innerhalb dieser resource groups deployt hat, werden ebenfalls gelöscht. Hole zuerst eine schriftliche Bestätigung des workload-Owners ein.

Anfragefelder

Feld Verwendung
Name Identifiziert die spoke-Datei(en): workloadShortName, Dateiname
Begründung Change-Eintrag
Umgebung Welche spoke-Umgebung(en) entfernt werden sollen (dev, tst, acc, prd, shared)
Nutzungsart (Produktionsdaten ja/nein) Wenn ja: Datenaufbewahrung/Backup vor dem Löschen bestätigen
Kommentare

Schritte

1. Datei finden und prüfen, was vom spoke abhängt

  • spoke-Datei: <env-folder>/spokes/**/<file>.json.
  • Durchsuche das Konfigurations-Repository nach den Adressbereichen und dem Namen des spokes, in:
  • IP groups (ip_groups/*.json),
  • Firewallregeln (firewall_rule_configuration/*.json),
  • Application-Gateway-JSON.

Das sind Hub-Ressourcen. Das destroy des spokes entfernt sie nicht.

2. destroy-Pipeline nur für diese Datei ausführen

Führe spoke-destroy aus, mit spokeGlob auf genau diese Datei gesetzt, zum Beispiel team-a/canvas_app1_dev.json.

  • Azure DevOps: Pipelines → spoke-destroy → Run pipeline → spokeGlob = team-a/canvas_app1_dev.json.
  • GitHub Actions: Actions → spoke-destroy → Run workflow → spokeGlob = team-a/canvas_app1_dev.json.

Das Referenz-Konfigurations-Repository verwendet none als Standardwert für spokeGlob, sodass ein Lauf ohne Eingabe nichts findet und in Prepare fehlschlägt („did not match any spoke JSON files“), bevor irgendetwas zerstört wird. Behalte diesen Standardwert bei.

Verwende dieselbe Plattformumgebung wie beim Deployment. spoke-destroy muss dieselbe mcp.json übergeben wie der spoke- Lauf, der den spoke erstellt hat. Im Referenz-Konfigurations-Repository zielt spoke.yaml auf prod, während spoke-destroy.yaml auf canary zielt. Gleiche sie ab, bevor du sie verwendest.

Prüfe zuerst die Entry-Datei. - mode: Apply bedeutet, dass es keinen Genehmigungsstopp gibt, bevor das destroy angewendet wird. - whatIf: true bedeutet, dass nur der destroy-Plan erzeugt wird.

Führe die Pipeline einmal mit whatIf: true aus und lies den destroy-Plan. Führe sie dann erneut mit whatIf: false aus. Siehe Pipelines und Workflows.

Was zerstört wird

Alles im spoke-state spoke_<wl>_<env>.tfstate:

  • die virtual hub connection in der Connectivity-subscription;
  • die virtuellen Netzwerke, Subnetze, NSGs, Regeln, Route Tables und Zuordnungen;
  • die private DNS zone und ihr Hub-Link (falls privatedns.name gesetzt war);
  • die resource group(s) und alles darin, einschließlich Key Vault, Storage Account und Log Analytics Workspace;
  • die Entra ID-Gruppen SG_SPOKE_<wl>_<env>_*, die PIM-Einstellungen, der Service Principal und seine Rollenzuweisungen;
  • das Azure DevOps-Repository und die service connection (falls azdo gesetzt war);
  • die Zuordnung zur management group, wenn sie im spoke-state enthalten ist (modules/subscription_managementgroup/main.tf). Das Löschen einer Zuordnung legt die subscription normalerweise zurück in die Standard-management-group des Tenants. Prüfe, wo die subscription anschließend landet. Siehe auch das bekannte Problem zu dieser Zuordnung in Bekannte Probleme.

Nicht verändert:

  • der subscription layer (<wl>_<env>_Subscription.tfstate). Über die Pipeline wird die subscription nie gekündigt (Invoke-XebiaSpokeApplyAction.ps1: das destroy der subscription ist ausdrücklich blockiert);
  • die subscription-Tags und der subscription-Name. Sie werden mit azapi_update_resource / azapi_resource_action gesetzt, die beim destroy nicht zurückgesetzt werden.

3. Hub-Referenzen aufräumen

Entferne in einem Folge-pull request die Firewallregeln, IP-group-Einträge und die Application-Gateway-Konfiguration, die du in Schritt 1 gefunden hast. Führe dann hub aus (siehe Firewallregeln und Application Gateway).

4. subscription außer Betrieb nehmen

Nimm die subscription in dieser Reihenfolge außer Betrieb, damit du bis zu ihrem Verschwinden eine Spur ihres Status behältst.

  1. Prüfe, ob sie leer ist. Öffne die subscription im Azure-Portal und prüfe die resource groups. Nach dem destroy sollten keine Spoke-Ressourcen übrig sein. Lösche alles, was noch da ist, etwa Ressourcen, die das Workload-Team außerhalb der Spoke-resource-groups erstellt hat. Prüfe, dass kein Workload aktiv ist.
  2. Prüfe die Hub-Verbindung. Öffne in der Connectivity-subscription das Virtual WAN und prüfe Virtual network connections: Die Verbindung des Spokes muss verschwunden sein. Das destroy entfernt sie. Wurde der Spoke von Hand entfernt, entferne sie selbst, um das Netzwerk vollständig zu isolieren.
  3. Prüfe die Identität. Die Entra-ID-Gruppen SG_SPOKE_<wl>_<env>_* (Präfix je Plattform) und der Service Principal SPN-SPOKE-<wl>-<env> müssen verschwunden sein. Das destroy entfernt sie. Falls es nicht lief, entferne sie von Hand. Dafür brauchst du eine Rolle, die Gruppen und App-Registrierungen löschen kann.
  4. Parke die subscription. Die Plattform hat eine management group decommissioned (management_group_structure.decommissioned). Verschiebe die subscription dorthin, damit alle sehen, dass sie auf dem Weg nach draußen ist. Um das per Code zu tun, füge ihre ID in foundation.auto.tfvars der primären Region zu decommissioned.subscription_ids hinzu und führe dann hub aus. Siehe den Hinweis in Sandbox-subscription.
  5. Kündige die subscription im Portal (subscription-Übersicht > Cancel subscription) oder über deinen Abrechnungsprozess (EA/MCA/CSP). Azure behält die subscription danach für eine Karenzzeit, bevor es die subscription und ihre Daten endgültig löscht. Notiere das Kündigungsdatum im Change-Eintrag und prüfe am Ende der Karenzzeit, dass die subscription verschwunden ist. Prüfe die Länge der Frist in der Dokumentation von Microsoft, denn sie hängt vom Typ der subscription ab.

5. spoke-Datei entfernen

Lösche die spoke-JSON (oder benenne sie in .json.ignore um) und führe den Merge durch. Wenn du das nicht tust, erstellt der nächste spoke-Lauf mit einem breiten Glob den spoke neu.

6. IP-Bereich freigeben

Entferne den Adressbereich des Spokes aus dem IP-Plan, damit er erneut vergeben werden kann. Tu das erst, wenn du sicher bist, dass im hub (Firewallregeln, IP groups, Routen, DNS) nichts mehr auf den Bereich verweist.

Prüfen

  • Der Apply-Job von spoke-destroy ist grün, und sein Plan zeigte nur destroy-Aktionen.
  • Connectivity-subscription → Virtual WAN → Virtual network connections: Das spoke-VNet ist verschwunden.
  • Die Gruppen SG_SPOKE_<wl>_<env>_* und die App-Registrierung SPN-SPOKE-<wl>-<env> sind verschwunden.

Rollback

Ein destroy kann nicht rückgängig gemacht werden. Wenn du Neuer spoke mit derselben Datei ausführst, wird das canvas neu erstellt, aber Daten im Storage und alles, was der workload deployt hat, sind weg.

Der Key Vault ist ein Sonderfall. Der spoke-Provider setzt purge_soft_delete_on_destroy = true und recover_soft_deleted_key_vaults = true (spoke-canvas/deploy/spoke/providers.tf). Purge Protection ist aktiviert, wenn SoftDeleteRetentionInDays nicht 0 ist (modules/keyvault/main.tf). Mit Purge Protection bleibt der Vault nach dem destroy soft-deleted. Eine Neuerstellung mit demselben Namen stellt diesen Vault wieder her, mit seinen alten Keys und Secrets, anstatt einen leeren zu erstellen.