Ga naar inhoud

Platform: wat het is en hoe het werkt

Dit gedeelte is voor platform engineers: XMMS-engineers in het managed model, of het eigen platformteam van de klant in het zelfbeheermodel (Beheermodellen). Het legt uit wat het platform technisch is, hoe het wordt uitgerold, en hoe je het bouwt, released en configureert.

Ik wil… Lees
De architectuur begrijpen Deze pagina. Voor de redenering erachter, zie de Architectuurreferentie
De volgorde begrijpen waarin alles wordt uitgerold Platform deploy flow
Weten welke repository wat bevat Repo-opzet
Aan de code werken: tools, provisioning, nieuwe features, releases Code
De configuratie van een klant wijzigen (hub of spoke) Config
Een klant upgraden naar een nieuwe versie Wat te doen als een nieuwe versie wordt gereleased
Het platform dagelijks beheren Operations, Incidentmanagement, Maandelijkse healthcheck, Onderhoudskalender
Firewallregels, regio's, DNS, agents en VPN-toegang inrichten Ontwerprichtlijnen
Het platform in een nieuwe tenant implementeren (plannen, voorbereiden, deployen, valideren, overdragen) Het platform implementeren
Een standaardwijziging stap voor stap afhandelen (runbooks voor operator en reviewer) Runbooks voor reviewer en operator
De templatebibliotheek onderhouden Managed Templates
Zien wat er per versie is veranderd, versiespecifieke upgradestappen uitvoeren Releases en upgradebegeleiding, Releasegeschiedenis
Alerting begrijpen en inrichten Monitoring en alerting
Pipelines, agents en lokale toegang troubleshooten Troubleshooting how-to's
Weten welke Azure-resources het platform deployt, en welke schakelaar erbij hoort Wat het platform deployt
Begrijpen hoe klantkopieën van de coderepository actueel blijven Codesynchronisatie
Governance, rollen en het DNS-ontwerp begrijpen Governance, Identiteits- en toegangsmodel, DNS-ontwerp

Wat wordt er uitgerold

Het platform bestaat uit:

  • een hub: gedeelde netwerk-, security-, governance- en monitoringvoorzieningen die elke workload gebruikt, en
  • spokes: één subscription per workload en spoke-omgeving, vooraf aangesloten op de hub.

Alles wordt uitgerold met Terraform, georkestreerd door een PowerShell-module (src/Xebia.Mcp), en draait vanuit Azure DevOps pipelines of GitHub Actions workflows.

Management group-structuur

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

De betekenis van elk niveau staat uitgelegd in Architectuurreferentie.

De structuur wordt aangemaakt door infra/templates/management_groups/main.tf. Namen en ID's worden ingesteld in <env-folder>/<primary region>/foundation.auto.tfvars (management_group_structure en de mgmtgrp_structure_under_customer_area_* maps).

Netwerk

  • Virtual WAN met een virtual hub per regio. De Virtual WAN wordt altijd in de primaire regio aangemaakt; elke regio krijgt een eigen virtual hub. Azure Firewall wordt in de virtual hub uitgerold, waardoor het een secured virtual hub wordt.
  • Spokes verbinden via een virtual hub connection, niet via klassieke VNet-peering. Met internet_security_enabled = true (de standaardwaarde) loopt het internetverkeer van spokes via de hub-firewall.
  • Firewallregels en IP groups zijn JSON-bestanden in de configuratierepository, uitgerold door de firewall layer. Zie Organisatie van firewallregels voor hoe je ze structureert.
  • Private DNS: centrale private DNS-zones voor private endpoints en een Private DNS Resolver. Een Azure Policy initiative registreert DNS-records van private endpoints automatisch in de centrale zones. Zie DNS-ontwerp.
  • Optioneel: site-to-site VPN, point-to-site VPN, ExpressRoute, Application Gateway met WAF, Azure Bastion, DDoS protection, Azure Virtual Network Manager met IPAM. Alle schakelaars staan in de feature flags-referentie.

Governance

  • Ingebouwde compliance initiatives op de cloudplatform management group: ISO 27001:2013, CIS 1.4.0, CIS 3.0.0, Microsoft cloud security benchmark en NIS2 (postdeployment layer).
  • Custom policy definitions en initiatives vanuit JSON in de configuratierepository (foundation layer).
  • Policy assignments en exemptions vanuit JSON in de configuratierepository (postdeployment layer).
  • Microsoft Defender for Cloud voor de platform subscriptions, en optioneel voor spokes.

Monitoring

  • Action groups (ag-<company>-mgmtgeneral-… en ag-<company>-mgmtxpirit-…), aangemaakt door de foundation layer.
  • Azure Monitor Baseline Alerts (AMBA): vijf initiatives (Service Health, Management, Connectivity, Identity, Landing Zone) die per management group worden toegewezen door de postdeployment layer.
  • Alert processing rules routeren platformalerts naar de action groups.
  • Optionele 24/7-routering van de hub (hub_247_support) stuurt geselecteerde hubalerts buiten kantooruren naar een webhook (ADR-0007).

Spokes

Voor elk spoke JSON-bestand maakt of werkt de spoke pipeline in de spoke subscription het volgende bij:

  • subscription tags, naam en plaatsing in de management group
  • resource groups, virtual networks, subnets, NSG's en route tables
  • de virtual hub connection
  • een Log Analytics workspace, Key Vault en storage account (standaard aan)
  • Entra ID-groepen (Owners, Contributors, Readers, Support) met PIM-instellingen
  • een service principal met role assignments
  • optioneel een Azure DevOps repository en service connection

Deployment-tooling

De pipelines draaien in een container image (mcp) op self-hosted runners in de JobRunner subscription uit mcp.json: een virtual network met NAT gateway, een Azure Container Registry, een Managed DevOps Pool, een Container Apps environment en een DNS resolver. Terraform state wordt opgeslagen in de storage accounts in mcp.json (Azure.TerraformState.Hub en .Spoke).

Hoe het werkt, in één plaatje

flowchart LR
    subgraph code["xms-cloud-platform-code (één voor alle klanten)"]
        tf["Terraform layers + modules"]
        mod["Xebia.Mcp PowerShell module"]
        tpl["Pipeline templates"]
    end
    subgraph cfg["Configuratierepository (één per klant)"]
        json["mcp.json, tfvars, JSON"]
        entry["Entry pipelines (vastgepinde versie)"]
    end
    entry -- "checks out release/vX.Y" --> tpl
    tpl --> mod
    mod -- "terraform plan / apply" --> tf
    json -- "values" --> mod
    mod --> azure["Azure: canary, then prod"]

Waarom het zo is gebouwd

Ontwerpkeuze Reden
Coderepository gescheiden van configuratierepository Eén gedeelde, geversioneerde codebase bedient veel tenants. Elke tenant houdt alleen de eigen waarden.
Layers in plaats van één Terraform root Kleinere blast radius, snellere plans, een duidelijke afhankelijkheidsvolgorde. Zie Deployment layers.
JSON-bestanden voor regels, policies en spokes Mensen die geen Terraform schrijven kunnen wijzigingen reviewen. Schema's en config tests valideren bestanden vóór deployment.
Logica in een PowerShell-module, dunne YAML Azure DevOps en GitHub Actions gedragen zich hetzelfde, en elke stap kan lokaal draaien (ADR-0011).
Canary-platformomgeving Elke code- of configwijziging wordt bewezen op een volledige kopie van de hub voordat die productie bereikt.

Zie Platformfilosofie voor de principes achter deze keuzes. De servicetypes (core, direct, additional) en de spoke-varianten worden beschreven in Servicetypes.