Een regio toevoegen¶

Veelvoorkomende aanvraag: Een regio toevoegen aan de hub (bijvoorbeeld een tweede regio voor disaster recovery of dataresidentie).

Effect: de platformomgeving krijgt een tweede virtual hub in de nieuwe regio, verbonden met dezelfde Virtual WAN, met een eigen firewall, DNS-, identity- en managementnetwerken. Spokes kunnen de regio daarna gebruiken.

Status van dit runbook

Dit runbook is geschreven op basis van de code (Get-XebiaRegion.ps1, Set-XebiaRegionMatrix.ps1, de count-guards in de layers) en de Demo-configuratie met twee regio's (config/Demo/canary, weu + neu). Valideer het op canary en verfijn het na de eerste regiotoevoeging bij een klant.

Aanvraagvelden¶

Aanvraagveld	Waar het terechtkomt	Opmerkingen
Regio	`active_regions`, `active_regions_names`, nieuwe `<region>/`-map	Azure-naam (`swedencentral`) en korte naam (`sdc`). De korte naam wordt gebruikt in elke resourcenaam en state-sleutel.
Onderbouwing	PR / wijzigingsrecord	DR, latency, dataresidentie, …
Omgeving	`canary` en/of `prod`	Doe eerst canary.
Adresbereiken	`<region>/connectivity.auto.tfvars`, `identity.auto.tfvars`, `management.auto.tfvars`	Virtual hub-prefix, subnets van het hub-VNet, identity- en management-VNets. Mogen niet overlappen met een andere regio of spoke.
Features in de regio	`<region>/<layer>.auto.tfvars`	Firewall, VPN/ExpressRoute, App Gateway, Bastion, private DNS zones.
Opmerkingen	–

Hoe regio's in de code werken¶

Regio's komen uit <env-folder>/global.auto.tfvars:

primary_region       = "weu"
active_regions       = ["weu", "neu"]
active_regions_names = ["westeurope", "northeurope"]

Level 1 draait foundation en connectivity in de primaire regio; level 2 draait ze in elke andere regio; level 3 draait firewall, identity en management in alle regio's; level 4 draait postdeployment alleen in de primaire regio.
Resources die één keer per platformomgeving bestaan (management groups, policy-definities en -toewijzingen, alert initiatives) zijn beveiligd met count = var.scaffold_location_short_name == var.primary_region ? 1 : 0, zodat ze niet gedupliceerd worden in de nieuwe regio.
De Virtual WAN wordt aangemaakt door de primaire regio; de nieuwe regio voegt er een virtual hub aan toe.
Wijzig nooit primary_region van een draaiend platform. Daarmee verhuist elke resource die alleen in de primaire regio bestaat naar een nieuwe state-sleutel.

Stappen¶

1. Adresbereiken reserveren¶

Reserveer vanuit het IP-plan, bijvoorbeeld (Demo gebruikt 10.160.0.0/… voor weu en 10.160.20.0/24 als virtual hub van neu):

Bereik	Variabele
Virtual hub	`virtual_hub_address_prefix` (connectivity)
Hub-VNet en subnets (Bastion, DNS resolver in/out, App Gateway)	subnetmap van het hub-VNet (connectivity)
DNS-server-IP van de regio	`virtual_network_dns_servers` (connectivity); spokes in de regio gebruiken dit standaard
Identity-VNet	identity
Management-VNet	management

2. De regio toevoegen aan `global.auto.tfvars`¶

Voeg de korte naam toe aan active_regions en de Azure-naam aan active_regions_names, op dezelfde positie:

primary_region       = "gwc"
active_regions       = ["gwc", "sdc"]
active_regions_names = ["germanywestcentral", "swedencentral"]

3. De regiomap aanmaken¶

Maak <env-folder>/<region>/ aan. Kopieer een bestaande niet-primaire regiomap als je die hebt, anders de map van de primaire regio, en pas daarna aan:

Bestand	Wijziging
`global.auto.tfvars`	`scaffold_location = "swedencentral"`, `scaffold_location_short_name = "sdc"`
`connectivity.auto.tfvars`	Nieuwe adresbereiken en DNS-server-IP. Zet feature flags voor deze regio. Laat `application_gateway_json_file_relative_path` / `web_application_firewall_policy_json_file_relative_path` naar mappen onder `sdc/…` wijzen.
`firewall.auto.tfvars`	`firewall_rule_collection_file_location = "sdc/firewall_rule_configuration"`, `ip_group_json_file_relative_path = "sdc/ip_groups/"`. Behoud de globale paden.
`identity.auto.tfvars`, `management.auto.tfvars`	Nieuwe VNet-bereiken.
`foundation.auto.tfvars`	Alleen de regionale waarden (bijvoorbeeld ontvangers van action groups). Instellingen die alleen voor de primaire regio gelden, zoals `management_group_structure`, hebben buiten de primaire regio geen effect; Demo `neu` gebruikt `management_group_structure = {}`.
`postdeployment.auto.tfvars`	Wordt niet gelezen: `postdeployment` draait alleen in de primaire regio. Je kunt het weglaten.

Schrijf elk pad relatief ten opzichte van de <env-folder> (waarom).

4. Firewallregels voor de regio toevoegen¶

Maak <region>/firewall_rule_configuration/ en <region>/ip_groups/ aan met de regels die de regio nodig heeft (minimaal de platformregels: job runners, DNS, Azure-services).
Met use_multiregion_fwp_rulecollectiongroup_naming = true worden bestanden in de globale firewall_rule_configuration/ voor elke regio samengevoegd; een regionaal bestand met dezelfde naam wint.
Voeg waar nodig regels toe voor verkeer tussen regio's.

5. Valideren en een pull request openen¶

Volg Veilig een wijziging doorvoeren, stappen 4–5. De config-tests valideren ook de JSON van de nieuwe regio.

6. Plan en apply op canary¶

Draai hub in de modus Plan of ApproveModifications. Verwacht:

Layer	Bestaande regio	Nieuwe regio
`foundation`	geen wijzigingen	alleen regionale resources (action groups, …)
`connectivity`	geen wijzigingen (controleer de Virtual WAN)	virtual hub, firewall, firewall policy, hub-VNet, DNS resolver, ingeschakelde gateways
`firewall`	geen wijzigingen	IP groups en rule collection groups
`identity`, `management`	geen wijzigingen	VNets en hub-connecties, regionale managementresources
`postdeployment`	geen wijzigingen	–

Stop als de bestaande regio destroys of replacements toont. Het aanmaken van een virtual hub en firewall duurt 30–60 minuten.

7. Controleren¶

Connectivity-subscription → Virtual WAN → Hubs: de nieuwe hub staat in de lijst en heeft status Succeeded.
Firewall Manager: de nieuwe hub is een secured hub met de verwachte policy.
De identity- en management-VNets van de nieuwe regio staan als verbonden.
Naamresolutie vanaf de DNS resolver van de nieuwe regio werkt voor een private endpoint-zone.

8. Herhaal voor prod¶

9. Spokes de regio laten gebruiken¶

Per spoke: voeg de regio toe aan targetRegions.additional en voeg een network[]-item toe met "region": "sdc" en minstens één subnet met "isprivatelinksubnet": true. Draai spoke voor dat bestand. Zie Spoke wijzigen.

Rollback¶

Verwijder de regio uit active_regions / active_regions_names pas nadat de resources zijn vernietigd (destroyed): een regio die niet meer in de matrix staat wordt helemaal niet meer gepland, waardoor de resources in Azure blijven staan met een verweesde state. Om een regio te verwijderen, verwijder je eerst alle spokes uit die regio, vernietig je daarna de layers lokaal met Remove-XebiaLocal -DeployName <layer> -Region <region> in omgekeerde volgorde, en pas daarna verwijder je de regio uit global.auto.tfvars.

Veelvoorkomende problemen¶

Symptoom	Oorzaak
`primary_region '<x>' is not in active_regions`	`primary_region` ontbreekt in `active_regions`
Regio wordt helemaal niet gedeployed	Regio ontbreekt in `active_regions`, of de regex in `Get-XebiaRegion.ps1` kan de lijst niet parsen (houd hem op één regel, dubbele aanhalingstekens)
Firewall-layer plant geen regels voor de nieuwe regio	Verkeerd relatief pad in `<region>/firewall.auto.tfvars`
Naamconflicten in Key Vault of storage	Globale namen bevatten de korte regionaam; kies een korte naam waarmee ze onder de Azure-limieten blijven