Een demo- of testdeployment opruimen

Demo-, test- en trainingsomgevingen, en mislukte implementatiepogingen, moeten weer worden verwijderd zodat ze geen geld kosten en geen objecten achterlaten in de tenant. Deze pagina beschrijft hoe je een platformomgeving afbreekt en hoe je hem daarna helemaal opnieuw opbouwt.

Alleen voor omgevingen die je kunt missen

Een destroy verwijdert het netwerk, de firewall, de policies en de management groups van de hub, en de spokes met hun Key Vaults en storage accounts. Gebruik het alleen op een demo- of test-platformomgeving, of op de canary-omgeving van een klant die hiermee akkoord is. Draai het nooit tegen een productie-platformomgeving. Controleer voordat je begint welke mcp.json de destroy pipeline als doel heeft.

Volgorde: eerst de spokes, dan de hub

1. Verwijder de spokes met de spoke-destroy pipeline, één spoke-bestand tegelijk (spokeGlob ingesteld op dat bestand). Gebruik dezelfde mcp.json als de spoke-run die ze heeft aangemaakt. De destroy hoort de spoke-omgevingen in de omgekeerde volgorde van de deployment te draaien (prd, acc, tst, dev). Controleer of jouw kopie van het entry-bestand dat doet, want oudere kopieën draaiden dev eerst (Bekende problemen). Details en de waarschuwing voor dataverlies: Een spoke verwijderen. De pipeline zegt de subscription niet op en draait de tags of de naam niet terug.
2. Verwijder de hub met de hub-destroy pipeline. Die draait de layers in omgekeerde volgorde: postdeployment, daarna firewall, identity en management, daarna connectivity, daarna foundation (Deployment layers), voor elke regio. In de referentie-configuratierepository richt hij zich alleen op canary.
3. Controleer wat er nog over is (zie hieronder).
4. Verwijder de job runners en de state alleen als de hele omgeving verdwijnt: de resource group van de runners, het Terraform state storage account, de service principals en de Azure DevOps- of GitHub-objecten.

Controleer de entry-bestanden voordat je ze draait: mode: Apply voert de destroy uit zonder goedkeuringsstop, en whatIf: true maakt er alleen een plan van. Draai één keer met whatIf: true, lees het destroy-plan, en draai opnieuw met whatIf: false (Pipelines).

Snijd je eigen agents niet af

Als het virtual network van de runners met internet_security_enabled = true met de hub is verbonden, haalt het destroyen van de connectivity layer de route van de agents naar Azure DevOps of GitHub weg, en kunnen de volgende stappen niet draaien. Voorkom dit door het runnernetwerk te verbinden met internet_security_enabled = false, of draai de laatste layers vanaf een andere runner (zie Netwerktoegang van de agents).

Wat er na een destroy kan blijven staan

Blijft staan	Waarom	Actie
Subscriptions, met hun tags en namen	De pipeline zegt subscriptions nooit op	Haal ze handmatig uit gebruik, of hergebruik ze (Een spoke verwijderen)
Soft-deleted Key Vaults	Soft delete en purge protection houden ze vast. Een Key Vault die met dezelfde naam opnieuw wordt aangemaakt, wordt hersteld met zijn oude secrets (recover_soft_deleted_key_vaults = true).	Purge ze als je een schone start wilt (Bekende problemen)
Custom policy definitions en initiatives op de management group	Oudere cleanup pipelines verwijderden de policy (set) definitions expliciet voordat de foundation layer werd gedestroyd	Maak een lijst van de custom definitions en set definitions op de platform-management group en verwijder wat is blijven staan
Management groups en role assignments	Een mislukte of gedeeltelijke destroy kan ze achterlaten	Controleer de management group-boom en de IAM van de platform-management group
Entra ID-groepen en service principals van spokes	Aangemaakt in de administrative unit door de spoke pipeline	Controleer of de spoke destroy ze heeft verwijderd
Terraform state-bestanden	Worden niet verwijderd door destroy	Verwijder de blobs van de verwijderde layers en spokes als je ze met andere waarden opnieuw aanmaakt
Resource groups van de job runners	Uitgerold door infrastructure, niet door de hub	Verwijder ze als de hele omgeving verdwijnt

Geplande opruiming van een demo-omgeving

Een demo-omgeving die af en toe wordt gebruikt, moet automatisch worden verwijderd. Een oudere cleanup pipeline deed dit voor de canary-platformomgeving volgens een schema (elke nacht): per regio destroyde hij de postdeployment-, firewall-, identity-, management- en connectivity-layers, verwijderde de policy (set) definitions en destroyde de foundation layer. De enige omgevingsspecifieke instelling was de ID van de platform-management group.

Hetzelfde kun je bouwen met een geplande run van hub-destroy voor de demo-platformomgeving. Houd twee regels aan:

• Plan het alleen op een omgeving die niets bevat wat je wilt bewaren.
• Draai de opruiming met de hand zodra je een demo of test hebt afgerond, zodat je 's nachts niet betaalt voor de ongebruikte omgeving.

Opnieuw helemaal vanaf nul uitrollen

Voor een gewone klant gebeurt een schone (eerste) deployment één keer. Voor een demo-omgeving die je regelmatig destroyt, gebeurt het elke keer. Een schone deployment vraagt om een vaste volgorde van layers en regio's, omdat ze van elkaar afhankelijk zijn voor resources zoals het virtual network: de hub pipeline regelt dat (Het platform uitrollen). Gebruik de volledige hub-run, niet losse layers.

Voordat je opnieuw draait:

• [ ] De job runners en de mcp image bestaan nog (of draai eerst infrastructure en container)
• [ ] Het state storage account en de spoke state container bestaan nog
• [ ] Achtergebleven policy definitions en soft-deleted Key Vaults zijn opgeruimd zoals hierboven
• [ ] De subscriptions staan weer onder de platform-management group (een nieuwe management group-boom wordt aangemaakt door de foundation layer)
• [ ] De configuratie komt nog overeen met je doel. Verwijder de spoke-bestanden van de spokes die je hebt gedestroyd, anders maakt de volgende spoke- run ze opnieuw aan.