Managed Templates: de templatebibliotheek¶
Managed Templates (XMT) is een bibliotheek met kant-en-klare, geteste infrastructuurmodules in Terraform en Bicep. Workload teams gebruiken ze om hun resources in een spoke te bouwen op een manier die de standaarden van het platform volgt, zonder zelf elke policy en baseline bij te hoeven houden. De bibliotheek bevat ook een IaC Accelerator: een werkend voorbeeldproject dat laat zien hoe je je code structureert, de modules aanroept en met een pipeline deployt.
Dit onderdeel heeft twee lezers. Workload teams lezen hoe ze de bibliotheek gebruiken in Managed Templates gebruiken, de modulecatalogus en de IaC Accelerator. De mensen die de bibliotheek onderhouden lezen hoe die is gebouwd, getest en uitgebracht.
Een optioneel aanbod, los van het platform
De templatebibliotheek maakt geen deel uit van de kern-code van de MCP hub en spoke, en heeft een eigen repository, pipelines, tests en versies. Of je platform hem heeft, wie hem onderhoudt en hoe de modules aan jou worden geleverd, bepaalt je platformteam (Beheermodellen). De pagina's beschrijven hoe de bibliotheek in zijn referentievorm is opgebouwd. Jouw bibliotheek kan afwijken.
Wat de bibliotheek is¶
| Eigenschap | Wat het betekent |
|---|---|
| Een module per Azure-resourcetype | Elke module verpakt één resourcetype (bijvoorbeeld een storage account of een Key Vault), met de instellingen die een workload team nodig heeft. Sommige Terraform-modules zijn patronen die meerdere modules combineren. Zie de modulecatalogus. |
| Gebouwd op Azure Verified Modules | De modules roepen de Azure Verified Modules (AVM) van Microsoft aan en geven hun parameters en outputs door. De bibliotheek voegt de standaarden van het platform daaraan toe. Enkele modules bezitten hun eigen resourcelogica (zie de catalogus). |
| Policy-compliant by design | Waarden die een Azure Policy controleert zijn in de module vastgezet, zodat een team geen resource kan deployen die de baseline schendt. De doelbaselines zijn de CIS Microsoft Azure Foundations Benchmark 2.0, ISO 27001:2013 en de Microsoft cloud security benchmark. Zie Policy compliance. |
| Getest | Elke module wordt in een testsubscription gedeployed en getoetst aan de Azure policies van het platform. Zie Testen. |
| Versie per module | Een team pint de versie van elke module en bepaalt zelf wanneer het upgradet. Zie Versiebeheer. |
| Gedocumenteerd | De referentie van elke module (parameters, outputs) wordt uit de code gegenereerd. Zie Release en documentatie. |
| Terraform en Bicep | Beide technologieën staan in één repository en één product, in aparte mappen. |
| Onderhouden | De bibliotheek wordt bij elke wijziging en wekelijks op schema getest, en de modules worden bijgewerkt als de baselines of de upstream-modules veranderen. |
Wie doet wat¶
De bibliotheek heeft een onderhoudend team en afnemende teams. Wie welke rol invult, hangt af van het beheermodel van je platform (Beheermodellen).
| Rol | Onder een managed-service-contract | Bij zelfbeheer |
|---|---|---|
| Onderhoudend team: bouwt, test, versioneert en released de modules, en levert ze aan de afnemer | XMMS | Het team van de klant dat de bibliotheek bezit |
| XMT Ambassador: regelt toegang en onboarding aan de kant van de afnemer, en is het eerste aanspreekpunt voor vragen | Een persoon van de klant | Een persoon van het platformteam van de klant |
| Workload team: roept de modules aan in de eigen code, pint versies, deployt via een pipeline | Het workload team | Het workload team |
Het workload team blijft verantwoordelijk voor de eigen infrastructuurcode en voor het deployen ervan. Een module vermindert het policywerk, maar is geen garantie dat een workload compliant is (Verantwoordelijkheden).
Wat er in dit onderdeel staat¶
| Pagina | Inhoud |
|---|---|
| Managed Templates gebruiken | Een module refereren, toegang krijgen in een pipeline, versies kiezen en upgraden |
| Modulecatalogus | Alle modules per service, met wat ze deployen en of ze in Terraform en Bicep bestaan |
| IaC Accelerator | Het kant-en-klare voorbeeldproject met structuur, pipeline en geautomatiseerde dependency-updates |
| Policy compliance | Hoe modules policies afdwingen, en de bevindingen die je nog in Azure Policy ziet |
| Toegang instellen (XMT Ambassador) | De eenmalige inrichting en het toegangsbeheer aan de kant van de afnemer |
| Repositorystructuur | De mappen van de repository en wat elke map bevat |
| Testen | De testaanpak: integratietests, Azure Policy-compliance, gedeelde resources |
| Pipelines en scripts | De pipelines en de hulpscripts van de repository |
| Versiebeheer | Semantic versioning per module, de changelog en upgrade notes |
| Release en documentatie | Releaseproces, gegenereerde documentatie, levering aan afnemers |
| Modules maken en bijdragen | Een nieuwe module maken, fixes van upstream-modules, bijdragegids |
| Samenvattingen van besluiten | De besluiten achter het ontwerp, in het kort |
Hoe het in het platform past¶
flowchart LR
avm["Azure Verified Modules (upstream)"] --> xmt["Managed Templates library"]
pol["Azure Policy of the platform"] --> xmt
xmt -->|"versioned releases"| ws["Workload team code in a spoke"]
acc["IaC Accelerator (example project)"] -.->|"copy and adapt"| ws
ws --> spoke["Spoke (baseline of the platform)"]De modules gaan uit van de baseline van een spoke: private connectiviteit, de policies op de management groups en de gedeelde resources. Ze zijn een manier om te voldoen, geen manier om de policies te omzeilen. Een resource die een module niet op een compliant manier kan aanmaken is een reden om de module uit te breiden, of om een uitzondering aan te vragen (Policy-uitzonderingen).