Region hinzufügen¶

Häufige Anfrage: Eine Region zum Hub hinzufügen (zum Beispiel eine zweite Region für Disaster Recovery oder Datenresidenz).

Auswirkung: Die Plattformumgebung erhält in der neuen Region einen zweiten virtual hub, der mit demselben Virtual WAN verbunden ist und über eigene firewall-, DNS-, Identity- und Management-Netzwerke verfügt. spokes können die Region anschließend nutzen.

Status dieses Runbooks

Dieses Runbook wurde anhand des Codes (Get-XebiaRegion.ps1, Set-XebiaRegionMatrix.ps1, die layer-count-Guards) und der Demo-Konfiguration mit zwei Regionen (config/Demo/canary, weu + neu) geschrieben. Validiere es auf canary und verfeinere es nach dem ersten Hinzufügen einer Region für einen Kunden.

Anfragefelder¶

Anfragefeld	Wo es hingehört	Hinweise
Region	`active_regions`, `active_regions_names`, neuer `<region>/`-Ordner	Azure-Name (`swedencentral`) und Kurzname (`sdc`). Der Kurzname wird in jedem Ressourcennamen und jedem state key verwendet.
Begründung	PR / Change-Eintrag	DR, Latenz, Datenresidenz, …
Umgebung	`canary` und/oder `prod`	Zuerst canary.
Adressbereiche	`<region>/connectivity.auto.tfvars`, `identity.auto.tfvars`, `management.auto.tfvars`	Virtual-Hub-Präfix, Hub-VNet-Subnetze, Identity- und Management-VNets. Dürfen sich nicht mit anderen Regionen oder spokes überschneiden.
Features in der Region	`<region>/<layer>.auto.tfvars`	Firewall, VPN/ExpressRoute, App Gateway, Bastion, private DNS zones.
Kommentare	–

Wie Regionen im Code funktionieren¶

Regionen stammen aus <env-folder>/global.auto.tfvars:

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

Level 1 führt foundation und connectivity in der primären Region aus; Level 2 führt sie in jeder anderen Region aus; Level 3 führt firewall, identity und management in allen Regionen aus; Level 4 führt postdeployment nur in der primären Region aus.
Ressourcen, die pro Plattformumgebung nur einmal existieren (management groups, Policy-Definitionen und -Zuweisungen, Alert- initiatives), sind mit count = var.scaffold_location_short_name == var.primary_region ? 1 : 0 abgesichert, sodass sie in der neuen Region nicht dupliziert werden.
Das Virtual WAN wird von der primären Region erstellt; die neue Region fügt ihm einen virtual hub hinzu.
Ändere niemals primary_region einer laufenden Plattform. Dadurch wandert jede Ressource, die nur in der primären Region existiert, auf einen neuen state key.

Schritte¶

1. Adressbereiche reservieren¶

Reserviere aus dem IP-Plan, zum Beispiel (Demo verwendet 10.160.0.0/… für weu und 10.160.20.0/24 als virtual hub von neu):

Bereich	Variable
Virtual hub	`virtual_hub_address_prefix` (connectivity)
Hub-VNet und Subnetze (Bastion, DNS resolver in/out, App Gateway)	Subnetz-Map des Hub-VNets (connectivity)
DNS-Server-IP der Region	`virtual_network_dns_servers` (connectivity); spokes in der Region verwenden sie standardmäßig
Identity-VNet	identity
Management-VNet	management

2. Region in `global.auto.tfvars` eintragen¶

Hänge den Kurznamen an active_regions und den Azure-Namen an active_regions_names an, an derselben Position:

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

3. Region-Ordner erstellen¶

Erstelle <env-folder>/<region>/. Kopiere einen vorhandenen Ordner einer nicht primären Region, falls vorhanden, andernfalls den Ordner der primären Region, und passe ihn dann an:

Datei	Änderung
`global.auto.tfvars`	`scaffold_location = "swedencentral"`, `scaffold_location_short_name = "sdc"`
`connectivity.auto.tfvars`	Neue Adressbereiche und DNS-Server-IP. Setze die feature flags für diese Region. Richte `application_gateway_json_file_relative_path` / `web_application_firewall_policy_json_file_relative_path` auf die Ordner `sdc/…`.
`firewall.auto.tfvars`	`firewall_rule_collection_file_location = "sdc/firewall_rule_configuration"`, `ip_group_json_file_relative_path = "sdc/ip_groups/"`. Behalte die globalen Pfade bei.
`identity.auto.tfvars`, `management.auto.tfvars`	Neue VNet-Bereiche.
`foundation.auto.tfvars`	Nur die regionalen Werte (zum Beispiel Empfänger von action groups). Einstellungen, die nur für die primäre Region gelten, wie `management_group_structure`, haben außerhalb der primären Region keine Wirkung; Demo `neu` verwendet `management_group_structure = {}`.
`postdeployment.auto.tfvars`	Wird nicht gelesen: `postdeployment` läuft nur in der primären Region. Du kannst die Datei weglassen.

Schreibe jeden Pfad relativ zum <env-folder> (Begründung).

4. Firewallregeln für die Region hinzufügen¶

Erstelle <region>/firewall_rule_configuration/ und <region>/ip_groups/ mit den Regeln, die die Region braucht (mindestens die Plattformregeln: job runners, DNS, Azure-Dienste).
Mit use_multiregion_fwp_rulecollectiongroup_naming = true werden Dateien aus dem globalen firewall_rule_configuration/ für jede Region zusammengeführt; eine regionale Datei mit demselben Namen hat Vorrang.
Füge bei Bedarf Regeln für Traffic zwischen Regionen hinzu.

5. Prüfen und pull request öffnen¶

Folge den Schritten 4–5 in Änderungen sicher durchführen. Die Konfigurationstests prüfen auch die JSON-Dateien der neuen Region.

6. Plan und Apply auf canary¶

Führe hub im Modus Plan oder ApproveModifications aus. Erwartet wird:

Layer	Bestehende Region	Neue Region
`foundation`	keine Änderungen	nur regionale Ressourcen (action groups, …)
`connectivity`	keine Änderungen (Virtual WAN prüfen)	virtual hub, firewall, Firewall-Policy, Hub-VNet, DNS resolver, aktivierte gateways
`firewall`	keine Änderungen	IP groups und rule collection groups
`identity`, `management`	keine Änderungen	VNets und Hub-Verbindungen, regionale Management-Ressourcen
`postdeployment`	keine Änderungen	–

Stoppe, wenn die bestehende Region destroys oder Ersetzungen anzeigt. Das Erstellen eines virtual hub und einer firewall dauert 30–60 Minuten.

7. Prüfen¶

Connectivity-subscription → Virtual WAN → Hubs: Der neue hub ist aufgelistet und Succeeded.
Firewall Manager: Der neue hub ist ein secured hub mit der erwarteten Policy.
Die Identity- und Management-VNets der neuen Region werden als verbunden angezeigt.
Die Namensauflösung über den DNS resolver der neuen Region funktioniert für eine private-endpoint-Zone.

8. Für prod wiederholen¶

9. spokes die Region nutzen lassen¶

Pro spoke: Füge die Region zu targetRegions.additional hinzu und ergänze einen network[]-Eintrag mit "region": "sdc" und mindestens einem Subnetz mit "isprivatelinksubnet": true. Führe spoke für diese Datei aus. Siehe spoke ändern.

Rollback¶

Entferne die Region erst nach dem destroy ihrer Ressourcen aus active_regions / active_regions_names: Eine Region, die nicht mehr in der Matrix steht, wird überhaupt nicht mehr geplant, sodass ihre Ressourcen mit verwaistem state in Azure bleiben. Um eine Region zu entfernen, entferne zuerst alle spokes aus ihr, führe dann ein destroy ihrer layer lokal mit Remove-XebiaLocal -DeployName <layer> -Region <region> in umgekehrter Reihenfolge aus und entferne sie erst danach aus global.auto.tfvars.

Häufige Probleme¶

Symptom	Ursache
`primary_region '<x>' is not in active_regions`	`primary_region` fehlt in `active_regions`
Region wird überhaupt nicht deployt	Region fehlt in `active_regions`, oder der Regex in `Get-XebiaRegion.ps1` kann die Liste nicht parsen (in einer Zeile belassen, doppelte Anführungszeichen)
firewall layer plant keine Regeln für die neue Region	Falscher relativer Pfad in `<region>/firewall.auto.tfvars`
Namenskonflikte bei Key Vault oder Storage	Globale Namen enthalten den Regionskurznamen; wähle einen Kurznamen, der sie unter den Azure-Limits hält