Ga naar inhoud

Een spoke verwijderen

Standaardwijziging: Verwijderen van workload/spokes/application landing zone (spoke canvas)

Effect: alles wat het spoke canvas in de subscription en in de hub heeft aangemaakt wordt vernietigd (destroyed), inclusief het netwerk. De subscription zelf wordt niet opgezegd. De tags en de naam worden niet teruggezet. De management group-koppeling kan ook worden verwijderd (zie Wat wordt vernietigd (destroyed)).

Dataverlies. Hiermee worden de resource groups, de Key Vault en het storage account van de spoke vernietigd (prevent_deletion_if_contains_resources = false in spoke-canvas/deploy/spoke/providers.tf). Resources die het workloadteam binnen die resource groups heeft gedeployed, worden ook verwijderd. Vraag eerst schriftelijke bevestiging van de workload-eigenaar.

Aanvraagvelden

Veld Gebruik
Name Identificeert de spoke-bestand(en): workloadShortName, bestandsnaam
Onderbouwing Wijzigingsrecord
Omgeving Welke spoke-omgeving(en) verwijderd moeten worden (dev, tst, acc, prd, shared)
Usage type (productiedata ja/nee) Zo ja: bevestig dataretentie/back-up voordat je verwijdert
Opmerkingen

Stappen

1. Zoek het bestand en controleer wat van de spoke afhankelijk is

  • Spoke-bestand: <env-folder>/spokes/**/<file>.json.
  • Zoek in de configuratierepository naar de adresbereiken en de naam van de spoke, in:
  • IP groups (ip_groups/*.json),
  • firewallregels (firewall_rule_configuration/*.json),
  • Application Gateway-JSON.

Dit zijn hub-resources. De destroy van de spoke verwijdert ze niet.

2. Draai de destroy-pipeline alleen voor dat bestand

Draai spoke-destroy met spokeGlob ingesteld op het exacte bestand, bijvoorbeeld 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.

De referentieconfiguratierepository gebruikt none als default spokeGlob, dus een run zonder invoer matcht niets en faalt in Prepare ("did not match any spoke JSON files") voordat er iets wordt vernietigd. Behoud deze default.

Gebruik dezelfde platformomgeving als bij de deployment. spoke-destroy moet dezelfde mcp.json meekrijgen als de spoke-run die de spoke heeft aangemaakt. In de referentieconfiguratierepository wijst spoke.yaml naar prod terwijl spoke-destroy.yaml naar canary wijst. Stem ze op elkaar af voordat je ze gebruikt.

Controleer eerst het entrybestand. - mode: Apply betekent dat er geen goedkeuringsstop is voordat de destroy wordt toegepast. - whatIf: true betekent dat alleen het destroy-plan wordt gemaakt.

Draai eenmaal met whatIf: true en lees het destroy-plan. Draai daarna opnieuw met whatIf: false. Zie Pipelines en workflows.

Wat wordt vernietigd (destroyed)

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

  • de virtual hub-connectie, in de connectivity-subscription;
  • de virtual network(s), subnets, NSG's, regels, route tables en koppelingen;
  • de private DNS zone en de hub-link ervan (als privatedns.name was gezet);
  • de resource group(s) en alles daarin, inclusief de Key Vault, het storage account en de Log Analytics workspace;
  • de Entra ID-groepen SG_SPOKE_<wl>_<env>_*, de PIM-instellingen, de service principal en de bijbehorende role assignments;
  • de Azure DevOps-repository en service connection (als azdo was gezet);
  • de management group-koppeling als die in de spoke-state staat (modules/subscription_managementgroup/main.tf). Het verwijderen van een koppeling zet de subscription normaal gesproken terug in de default management group van de tenant. Controleer waar de subscription daarna terechtkomt. Zie ook het bekende probleem over deze koppeling in Bekende problemen.

Niet gewijzigd:

  • de subscription-layer (<wl>_<env>_Subscription.tfstate). Via de pipeline wordt de subscription nooit opgezegd (Invoke-XebiaSpokeApplyAction.ps1: subscription destroy is expliciet geblokkeerd);
  • de subscription-tags en de subscription-naam. Ze worden gezet met azapi_update_resource / azapi_resource_action, die bij een destroy niet worden teruggezet.

3. Hub-verwijzingen opruimen

Verwijder in een vervolg-pull request de firewallregels, IP group-items en Application Gateway-configuratie die je in stap 1 hebt gevonden. Draai daarna hub (zie Firewallregels en Application Gateway).

4. De subscription decommissioneren

Zet de subscription in deze volgorde buiten gebruik, zodat je een spoor van de status houdt totdat hij weg is.

  1. Controleer dat hij leeg is. Open de subscription in de Azure portal en controleer de resource groups. Na de destroy zouden er geen spoke-resources meer moeten zijn. Verwijder wat er nog is, zoals resources die het workload team buiten de resource groups van de spoke heeft aangemaakt. Controleer dat er geen workload actief is.
  2. Controleer de hub-connectie. Open in de connectivity-subscription de Virtual WAN en controleer Virtual network connections: de connectie van de spoke moet weg zijn. De destroy verwijdert die. Is de spoke met de hand verwijderd, verwijder de connectie dan zelf voor volledige netwerkisolatie.
  3. Controleer de identiteit. De Entra ID-groepen SG_SPOKE_<wl>_<env>_* (prefix per platform) en de service principal SPN-SPOKE-<wl>-<env> moeten weg zijn. De destroy verwijdert ze. Als die niet is gedraaid, verwijder ze dan met de hand. Hiervoor is een rol nodig die groepen en app registrations kan verwijderen.
  4. Parkeer de subscription. Het platform heeft een decommissioned management group (management_group_structure.decommissioned). Verplaats de subscription daarheen, zodat iedereen kan zien dat hij op weg naar buiten is. Om dit met code te doen, voeg je de ID toe aan decommissioned.subscription_ids in de foundation.auto.tfvars van de primaire regio en draai je hub. Zie het voorbehoud in Sandbox-subscription.
  5. Zeg de subscription op in de portal (subscription-overzicht > Cancel subscription) of via je facturatieproces (EA/MCA/CSP). Azure bewaart de subscription daarna nog een bewaartermijn voordat hij de subscription en de data definitief verwijdert. Noteer de opzegdatum in het wijzigingsrecord en controleer aan het einde van de bewaartermijn dat de subscription weg is. Controleer de lengte van de termijn in de documentatie van Microsoft, want die hangt af van het type subscription.

5. Het spoke-bestand verwijderen

Verwijder de spoke-JSON (of hernoem hem naar .json.ignore) en merge. Doe je dat niet, dan maakt de volgende spoke-run met een brede glob de spoke opnieuw aan.

6. Het IP-bereik vrijgeven

Verwijder het adresbereik van de spoke uit het IP-plan, zodat het opnieuw kan worden toegewezen. Doe dit alleen als je zeker weet dat niets in de hub (firewallregels, IP groups, routes, DNS) nog naar het bereik verwijst.

Controleren

  • De Apply-job van spoke-destroy is groen, en het plan toonde alleen destroy-acties.
  • Connectivity-subscription → Virtual WAN → Virtual network connections: het spoke-VNet is verdwenen.
  • De groepen SG_SPOKE_<wl>_<env>_* en de app registration SPN-SPOKE-<wl>-<env> zijn verdwenen.

Rollback

Een destroy kan niet ongedaan worden gemaakt. Nieuwe spoke draaien met hetzelfde bestand maakt het canvas opnieuw aan, maar de storage-data en alles wat de workload had gedeployed zijn weg.

Key Vault is een bijzonder geval. De spoke-provider zet purge_soft_delete_on_destroy = true en recover_soft_deleted_key_vaults = true (spoke-canvas/deploy/spoke/providers.tf). Purge protection is ingeschakeld wanneer SoftDeleteRetentionInDays niet 0 is (modules/keyvault/main.tf). Met purge protection blijft de vault na de destroy soft-deleted. Bij opnieuw aanmaken met dezelfde naam wordt die vault hersteld, met de oude keys en secrets, in plaats van een lege aan te maken.