Provisioning¶

Wie der Code eine Plattformumgebung provisioniert, von der Build-Infrastruktur bis zum letzten Layer. Die Reihenfolge ist im Deploy-Flow der Plattform beschrieben; diese Seite erklärt die einzelnen Teile.

Schritt für Schritt, einschließlich des state storage accounts und der Service Connections: pipelines und Agents vorbereiten.

Infra: die Job Runner¶

Die infrastructure Pipeline (stage-infrastructure.yaml → Invoke-XebiaInfrastructure) deployt die Build-Infrastruktur aus src/Xebia.Mcp/Files/bicep/deploy/initialize/main.bicep in die subscription und resource group aus mcp.json → Azure.JobRunner:

Ressource	Konfiguriert durch (`mcp.json`)
Virtual network, Subnetze und NAT gateway	`Azure.JobRunner.IpAddressPrefixes` (`Vnet`, `AgentSubnet`, `PepSubnet`, `CaeSubnet`, `DnsResolverSubnet`)
Azure Container Registry	–
Managed DevOps Pool `<AgentPool>`	`AzureDevops.AgentPool`, `Azure.JobRunner.MaximumAgents`, `Azure.JobRunner.Sku`
Container Apps environment (für Container-Jobs, Pool `<AgentPool>-CTR`)	–
DNS resolver	–

Außerdem legt sie den Blob Container im hub-Terraform-State-Storage-Account an (Initialize-XebiaMcpTerraformStateContainer). Der Storage Account selbst, der spoke-State-Container und die Service Principals für das Deployment sind Voraussetzungen; keine Pipeline legt sie an.

Im Referenz-Konfigurations-Repository wird infrastructure.yaml per CI bei Änderungen an der Datei selbst oder an pipelines/variables.yaml getriggert und führt canary und prod mit sequenziellem Locking aus.

Container: das `mcp`-Image¶

Die container Pipeline (Invoke-XebiaContainer -Action Prepare|Build) baut src/Dockerfile aus der gepinnten Code-Version und pusht das Image in die ACR der Job Runner. Das Image enthält PowerShell 7, Terraform, die Azure CLI, das Modul Xebia.Mcp und das hub-Terraform (beim Build aus infra/ kopiert). Die Image-Namen stammen aus AzureDevops.ContainerImageName (normalerweise ["mcp"]).

Die Tags werden von Get-XebiaMcpContainerTags.ps1 gesetzt; siehe Releasing. Die Entry Pipelines laufen auf imageRef: mcp:latest.

Layer, pro Umgebung und Region¶

Die hub Pipeline provisioniert die hub-Layer für eine Plattformumgebung (eine mcp.json) pro Stage:

Umgebung. Der Name der Plattformumgebung ist der Name des Ordners, der mcp.json enthält, zum Beispiel canary oder prod. Er wird im State-Key verwendet und als config_path an Terraform übergeben.
Regionen. Die Region-Matrix wird aus <env-folder>/global.auto.tfvars aufgebaut (Get-XebiaRegion.ps1, Set-XebiaRegionMatrix.ps1):
```
primary_region       = "weu"
active_regions       = ["weu", "neu"]
active_regions_names = ["westeurope", "northeurope"]
```
primary_region muss in active_regions enthalten sein. Level 1 läuft in der primären Region, Level 2 in den anderen Regionen, Level 3 in allen Regionen und Level 4 (postdeployment) nur in der primären Region. 3. Layer. Für jeden Layer und jede Region plant das Modul Terraform aus terraform/cloud-platform/deploy/<layer> mit den Var-Dateien dieser Region und Umgebung und speichert den State in <env>-<region>-<layer>.tfstate. Siehe Deployment-Layer.

flowchart TB
    mcp["environments/prod/mcp.json"] --> env["Environment = prod<br/>config_path = environments/prod"]
    env --> g["global.auto.tfvars<br/>primary_region, active_regions"]
    g --> r1["weu (primary)"]
    g --> r2["neu"]
    r1 --> l1["foundation, connectivity (level 1)"]
    r2 --> l2["foundation, connectivity (level 2)"]
    r1 --> l3["firewall, identity, management (level 3)"]
    r2 --> l3
    r1 --> l4["postdeployment (level 4)"]

Spokes¶

Die spoke Pipeline provisioniert spokes mit dem Terraform in src/Xebia.Mcp/Files/terraform/spoke-canvas/:

Schritt	Terraform Root	State-Key
Subscription	`deploy/subscription`	`<wl>_<env>_Subscription.tfstate`
Spoke canvas	`deploy/spoke`	`spoke_<wl>_<env>.tfstate`

<wl> und <env> sind der kleingeschriebene workloadShortName und environment aus dem spoke-JSON. Siehe Spoke-Konfiguration.

Der subscription-Schritt kommt zuerst, damit das spoke canvas immer eine subscription hat, in der es arbeiten kann. Er ist bewusst ein eigener Schritt und kein Pool freier subscriptions: siehe Subscription-Provisioning. Was der canvas-Schritt erstellt, beschreibt Spoke canvas; seine Terraform-Inputs und -Outputs stehen in der Modulreferenz.

Lokales Provisioning¶

dev/dev.ps1 führt dieselben Funktionen lokal im Dev Container gegen MCP_CONFIG aus (Standard: config/Demo/canary/mcp.json). WhatIf ist aktiv, solange du nicht -SkipWhatIf übergibst.

pwsh ./dev/dev.ps1 -Action Test
pwsh ./dev/dev.ps1 -Action Infrastructure -SkipWhatIf
pwsh ./dev/dev.ps1 -Action Container -SkipTests

Zu hub-Layern und spokes siehe Einen einzelnen Layer lokal ausführen; die hub- und spoke-Aktionen von dev.ps1 funktionieren auf main noch nicht (Bekannte Probleme).