Zum Inhalt

Plattform: Was sie ist und wie sie funktioniert

Dieser Bereich richtet sich an Plattform-Engineer: XMMS-Engineers im managed Modell oder das eigene Plattform-Team des Kunden im Eigenbetrieb (Betriebsmodelle). Er erklärt, was die Plattform technisch ist, wie sie deployt wird und wie du sie baust, veröffentlichst und konfigurierst.

Ich möchte… Lies
Die Architektur verstehen Diese Seite. Zur Begründung siehe die Architekturreferenz
Die Reihenfolge verstehen, in der alles deployt wird Deploy-Ablauf der Plattform
Wissen, welches Repository was enthält Repo-Setup
Am Code arbeiten: Tools, Provisionierung, neue Features, releases Code
Die Konfiguration eines Kunden ändern (hub oder spoke) Config
Einen Kunden auf eine neue Version upgraden Was zu tun ist, wenn eine neue Version veröffentlicht wird
Die Plattform im Tagesbetrieb betreiben Betrieb, Incident-Management, Monatlicher Health Check, Wartungskalender
Firewallregeln, Regionen, DNS, Agents und VPN-Zugriff organisieren Design-Leitfaden
Die Plattform in einem neuen Tenant implementieren (planen, vorbereiten, deployen, validieren, übergeben) Die Plattform implementieren
Eine Standardänderung Schritt für Schritt abwickeln (Runbooks für Operator und Reviewer) Runbooks für Reviewer und Operator
Die Template-Bibliothek pflegen Managed Templates
Sehen, was sich pro Version geändert hat, und versionsspezifische Upgrade-Schritte ausführen Releases und Upgrade-Hinweise, Release-Historie
Alerting verstehen und einrichten Monitoring und Alerting
pipelines, Agents und lokalen Zugriff troubleshooten Troubleshooting-How-tos
Wissen, welche Azure-Ressourcen die Plattform deployt und welcher Schalter dazugehört Was die Plattform deployt
Verstehen, wie Kundenkopien des Code-Repositorys aktuell bleiben Code-Synchronisierung
Governance, Rollen und das DNS-Design verstehen Governance, Identitäts- und Zugriffsmodell, DNS-Design

Was deployt wird

Die Plattform besteht aus:

  • einem hub: gemeinsames Networking, Security, Governance und Monitoring, das jeder workload nutzt, und
  • spokes: eine subscription pro workload und spoke-Umgebung, vorverdrahtet mit dem hub.

Alles wird mit Terraform deployt, von einem PowerShell-Modul (src/Xebia.Mcp) orchestriert und aus Azure DevOps pipelines oder GitHub Actions Workflows ausgeführt.

Struktur der management groups

Tenant root
└── <organization management group>              (management_group_organization_id)
    └── cloudplatform
        ├── platform
        │   ├── platform_management   → Management subscription   (Log Analytics, Automation, Key Vault, storage)
        │   ├── platform_connectivity → Connectivity subscription (Virtual WAN, hub, Azure Firewall, gateways, DNS, App Gateway)
        │   └── platform_identity     → Identity subscription     (identity virtual network)
        ├── landingzones
        │   ├── landingzones_corp     → corp spoke subscriptions   (+ optional child groups)
        │   └── landingzones_online   → online spoke subscriptions (+ optional child groups)
        ├── shared                    (+ optional child groups)
        ├── sandbox
        └── decommissioned

Der Baum wird durch infra/templates/management_groups/main.tf erstellt. Namen und IDs werden in <env-folder>/<primary region>/foundation.auto.tfvars gesetzt (management_group_structure und die mgmtgrp_structure_under_customer_area_*-Maps).

Die Bedeutung jeder Ebene wird in der Architekturreferenz erklärt.

Netzwerk

  • Virtual WAN mit einem virtual hub pro Region. Das Virtual WAN wird immer in der primären Region erstellt; jede Region erhält ihren eigenen virtual hub. Azure Firewall wird in den virtual hub deployt, wodurch er zu einem secured virtual hub wird.
  • Spokes verbinden sich über eine virtual hub connection, nicht über klassisches VNet Peering. Mit internet_security_enabled = true (dem Default) läuft der Internetverkehr der spokes über die hub-firewall.
  • Firewallregeln und IP groups sind JSON-Dateien im Konfigurations-Repository, deployt vom layer firewall. Wie du sie strukturierst, siehe Organisation der Firewallregeln.
  • Private DNS: zentrale Private-DNS-Zonen für Private Endpoints und ein Private DNS Resolver. Eine Azure-Policy-initiative registriert DNS-Einträge für Private Endpoints automatisch in den zentralen Zonen. Siehe DNS-Design.
  • Optional: Site-to-Site-VPN, Point-to-Site-VPN, ExpressRoute, Application Gateway mit WAF, Azure Bastion, DDoS protection, Azure Virtual Network Manager mit IPAM. Alle Schalter stehen in der feature-flags-Referenz.

Governance

  • Eingebaute Compliance-initiatives an der management group cloudplatform: ISO 27001:2013, CIS 1.4.0, CIS 3.0.0, Microsoft cloud security benchmark und NIS2 (layer postdeployment).
  • Benutzerdefinierte Policy-Definitionen und initiatives aus JSON im Konfigurations-Repository (layer foundation).
  • Policy-Assignments und -Ausnahmen aus JSON im Konfigurations-Repository (layer postdeployment).
  • Microsoft Defender for Cloud für die Plattform-subscriptions und optional für spokes.

Monitoring

  • Action groups (ag-<company>-mgmtgeneral-… und ag-<company>-mgmtxpirit-…), erstellt vom layer foundation.
  • Azure Monitor Baseline Alerts (AMBA): fünf initiatives (Service Health, Management, Connectivity, Identity, Landing Zone), pro management group vom layer postdeployment zugewiesen.
  • Alert processing rules leiten Plattform-Alerts an die action groups weiter.
  • Optionales hub-24/7-Routing (hub_247_support) sendet ausgewählte hub-Alerts außerhalb der Bürozeiten an einen Webhook (ADR-0007).

Spokes

Für jede spoke-JSON-Datei erstellt oder aktualisiert die spoke-pipeline in der spoke-subscription:

  • subscription-Tags, Name und Platzierung in der management group
  • resource groups, virtual networks, Subnets, NSGs und Route Tables
  • die virtual hub connection
  • einen Log-Analytics-Workspace, Key Vault und ein Storage Account (standardmäßig aktiv)
  • Entra-ID-Gruppen (Owners, Contributors, Readers, Support) mit PIM-Einstellungen
  • einen Service Principal mit Rollenzuweisungen
  • optional ein Azure-DevOps-Repository und eine Service Connection

Deployment-Tooling

Die pipelines laufen in einem Container-Image (mcp) auf selbst gehosteten runners in der subscription JobRunner aus mcp.json: ein virtual network mit NAT Gateway, eine Azure Container Registry, ein Managed DevOps Pool, eine Container-Apps- Umgebung und ein DNS Resolver. Der Terraform state liegt in den Storage Accounts aus mcp.json (Azure.TerraformState.Hub und .Spoke).

Wie es funktioniert, in einem Bild

flowchart LR
    subgraph code["xms-cloud-platform-code (eines für alle Kunden)"]
        tf["Terraform layers + modules"]
        mod["Xebia.Mcp PowerShell module"]
        tpl["Pipeline-Templates"]
    end
    subgraph cfg["Konfigurations-Repository (eines pro Kunde)"]
        json["mcp.json, tfvars, JSON"]
        entry["Entry-pipelines (fixierte Version)"]
    end
    entry -- "checks out release/vX.Y" --> tpl
    tpl --> mod
    mod -- "terraform plan / apply" --> tf
    json -- "values" --> mod
    mod --> azure["Azure: canary, dann prod"]

Warum es so gebaut ist

Designentscheidung Begründung
Code-Repository getrennt vom Konfigurations-Repository Eine gemeinsame, versionierte Codebasis bedient viele Tenants. Jeder Tenant hält nur seine eigenen Werte.
Layers statt eines einzigen Terraform root Kleinerer Blast Radius, schnellere Pläne, eine klare Abhängigkeitsreihenfolge. Siehe Deployment-layers.
JSON-Dateien für Regeln, Policies und spokes Menschen, die kein Terraform schreiben, können Änderungen prüfen. Schemas und config tests validieren Dateien vor dem Deployment.
Logik in einem PowerShell-Modul, schlankes YAML Azure DevOps und GitHub Actions verhalten sich gleich, und jeder Schritt kann lokal laufen (ADR-0011).
Plattform-Umgebung canary Jede Code- oder Config-Änderung wird auf einer vollständigen Kopie des hub erprobt, bevor sie die Produktion erreicht.

Die Prinzipien hinter diesen Entscheidungen findest du unter Plattform-Philosophie. Die Service-Typen (Core, Direct, Additional) und die Spoke-Varianten sind in Service-Typen beschrieben.