Deployment layers¶
De hub is opgedeeld in aparte Terraform root modules, layers genoemd, in infra/deploy/<layer>/. Elke layer heeft een
eigen state-bestand en een eigen plan en apply, en draait in een vaste volgorde.
Waarom layers¶
De analyse achter de opdeling: Architectuurnotities.
- Blast radius. Een wijziging in een firewallregel plant alleen de
firewallstate. Die kan niet per ongeluk management groups of gateways raken. - Afhankelijkheidsvolgorde. Latere layers lezen resources die eerdere layers hebben aangemaakt, zoals de virtual hub, de firewall policy of de management groups.
- Snelheid en locking. Kleinere states plannen sneller, en runs op verschillende layers blokkeren elkaars state lock niet.
- Verschillende wijzigingsfrequentie. Firewallregels en policies veranderen wekelijks; gateways en de Virtual WAN zelden.
De layers¶
| Level | Layer | Regio's | Belangrijkste resources | Subscription |
|---|---|---|---|---|
| 1 | foundation |
primair | Management groups en subscription-plaatsing; custom policy definitions en initiatives; registratie van resource providers; action groups; activity log alerts; DDoS plan (optioneel); Azure Virtual Network Manager en IPAM pools (optioneel); Private DNS policy definitions | management, connectivity, identity |
| 1 | connectivity |
primair | Virtual WAN, virtual hub, Azure Firewall en firewall policy, VPN/ExpressRoute gateways, point-to-site VPN, private DNS zones en resolver, Bastion, Application Gateway en WAF policies, alert processing rule, hub 24/7 routing (optioneel) | connectivity |
| 2 | foundation |
overige regio's | Regionale onderdelen van foundation (bijvoorbeeld de regionale action groups) | zoals hierboven |
| 2 | connectivity |
overige regio's | Regionale hub van elke extra regio | connectivity |
| 3 | firewall |
alle | IP groups en firewall policy rule collection groups (uit JSON); Network Manager security admin rules (optioneel) | connectivity |
| 3 | identity |
alle | Identity virtual network en de bijbehorende virtual hub connection, alert processing rule | identity (+ connectivity) |
| 3 | management |
alle | Management virtual network en hub connection; Key Vault, Automation Account, Log Analytics, storage, Sentinel (optioneel); alert processing rule | management (+ connectivity) |
| 4 | postdeployment |
primair | Ingebouwde compliance initiatives; policy assignments en exemptions (uit JSON); Defender for Cloud-instellingen; AMBA alert initiatives | management |
Binnen level 1 en level 2 wacht connectivity op de foundation apply (in Plan mode plannen ze naast elkaar). Level 3 layers draaien parallel; level 4 wacht op alle drie.
Waar de volgorde is vastgelegd:
- Pipelines: als job-afhankelijkheden in
.azure-devops/pipelines/templates/stage-mcp-hub.yamlen alsneeds:in.github/workflows/stage-mcp-hub-deploy.yaml. De region matrix per level komt uitSet-XebiaRegionMatrix.ps1. - Lokale tooling:
src/Xebia.Mcp/Functions/Private/Config/Get-XebiaOrderedDeployments.ps1, gebruikt doorDeploy-,Remove-enUnlock-XebiaLocal.
Primaire en overige regio's komen uit primary_region en active_regions in <env-folder>/global.auto.tfvars.
Verschillende resources van foundation en postdeployment bestaan maar één keer per platformomgeving, ook al draait de layer in
meerdere regio's. Ze zijn beveiligd met count = var.scaffold_location_short_name == var.primary_region ? 1 : 0. Voorbeelden:
management groups, policy definitions, policy assignments en alert initiatives.
Layers die geen onderdeel zijn van de hub pipeline¶
infra/deploy/ghrunners en infra/deploy/policy_exemptions bestaan in de code, maar noch de hub pipeline templates
noch Get-XebiaOrderedDeployments nemen ze op. Alleen legacy pipelines gebruiken ze.
- Policy-uitzonderingen worden in plaats daarvan door de
postdeploymentlayer gedeployed. - Een
ghrunners.auto.tfvars-bestand in een configuratierepository heeft geen effect op de huidige hub pipeline. (Oudere update-runbooks noemenghrunnersnog als layer om te draaien; dat geldt alleen voor de legacymain.yamlpipelines.)
Destroy-volgorde¶
hub-destroy draait dezelfde layers in omgekeerde volgorde (postdeployment → … → foundation): zie de destroy jobs in
stage-mcp-hub.yaml en Remove-XebiaLocal, dat Get-XebiaOrderedDeployments -Reverse aanroept.
Parallelisme¶
| Layer | terraform -parallelism |
|---|---|
firewall |
1 (Azure Firewall Policy accepteert maar één update van een rule collection group tegelijk, ADR-0009) |
postdeployment |
10 |
| alle andere | 100 |
Ingesteld in Invoke-XebiaHubPlanAction.ps1 en Invoke-XebiaHubApplyAction.ps1. Een grote firewallwijziging duurt daardoor
merkbaar langer.
Terraform state¶
| Wat | Backend (mcp.json) |
State key |
|---|---|---|
| Hub layer | Azure.TerraformState.Hub |
<env>-<region>-<layer>.tfstate, bijv. prod-gwc-firewall.tfstate |
| Spoke subscription | Azure.TerraformState.Spoke |
<workloadShortName>_<environment>_Subscription.tfstate |
| Spoke canvas | Azure.TerraformState.Spoke |
spoke_<workloadShortName>_<environment>.tfstate |
<env> is de naam van de map die mcp.json bevat. Spoke keys staan in kleine letters. De backend gebruikt Entra ID-
authenticatie (use_azuread_auth=true), dus de deployment-identiteit heeft een data-plane rol nodig op het state storage account.
Welke wijziging raakt welke layer¶
| Wijziging | Layer(s) die wijzigingen tonen in het plan |
|---|---|
| Firewallregel of IP group | firewall |
| Application Gateway of WAF policy | connectivity |
| Hub feature switch (VPN, Bastion, App Gateway, DNS zones, …) | connectivity (de meeste switches), zie feature flags |
| Management group of subscription-plaatsing | foundation (primaire regio) |
| Custom policy definition of initiative | foundation (primaire regio) |
| Policy assignment of exemption, alert initiatives, Defender-instellingen | postdeployment |
| Log Analytics, Key Vault, Automation | management |
| Spoke-JSON | spoke pipeline (geen hub layer) |
De hub pipeline plant altijd alle layers. Een layer zonder wijzigingen geeft een leeg plan en een apply die niets doet. Om één layer te draaien gebruik je de lokale tooling, zie Eén layer lokaal draaien.