Managed Templates: die Template-Bibliothek¶
Managed Templates (XMT) ist eine Bibliothek fertiger, getesteter Infrastruktur-Module in Terraform und Bicep. Workload- Teams nutzen sie, um ihre Ressourcen in einem spoke so zu bauen, dass sie den Standards der Plattform folgen, ohne selbst jede Policy und Baseline im Blick behalten zu müssen. Die Bibliothek enthält außerdem einen IaC Accelerator: ein lauffähiges Beispielprojekt, das zeigt, wie du deinen Code strukturierst, die Module aufrufst und mit einer pipeline deployst.
Dieser Abschnitt richtet sich an zwei Zielgruppen. Workload-Teams finden in Managed Templates nutzen, im Modulkatalog und im IaC Accelerator, wie sie die Bibliothek verwenden. Die Menschen, die die Bibliothek pflegen, finden, wie sie aufgebaut, getestet und released wird.
Ein optionales Angebot, getrennt von der Plattform
Die Template-Bibliothek ist nicht Teil des Kerncodes von MCP hub und spoke, und sie hat ein eigenes Repository, eigene pipelines, Tests und Versionen. Ob deine Plattform sie hat, wer sie pflegt und wie dir die Module geliefert werden, legt dein Plattform-Team fest (Betriebsmodelle). Die Seiten beschreiben, wie die Bibliothek in ihrer Referenzform aufgebaut ist. Deine Bibliothek kann abweichen.
Was die Bibliothek ist¶
| Eigenschaft | Was sie bedeutet |
|---|---|
| Ein Modul pro Azure-Ressourcentyp | Jedes Modul kapselt einen Ressourcentyp (zum Beispiel ein storage account oder ein Key Vault) mit den Einstellungen, die ein workload-Team braucht. Einige Terraform-Module sind Patterns, die mehrere Module kombinieren. Siehe den Modulkatalog. |
| Auf Azure Verified Modules aufgebaut | Die Module rufen die Azure Verified Modules (AVM) von Microsoft auf und reichen deren Parameter und Outputs weiter. Die Bibliothek ergänzt darüber die Standards der Plattform. Einige wenige Module besitzen ihre Ressourcenlogik selbst (siehe den Katalog). |
| Policy-konform by design | Werte, die eine Azure Policy prüft, sind im Modul festgelegt, sodass ein Team keine Ressource deployen kann, die die Baseline verletzt. Die Ziel-Baselines sind CIS Microsoft Azure Foundations Benchmark 2.0, ISO 27001:2013 und der Microsoft Cloud Security Benchmark. Siehe Policy-Compliance. |
| Getestet | Jedes Modul wird in einer Test-subscription deployt und gegen die Azure Policies der Plattform geprüft. Siehe Testing. |
| Pro Modul versioniert | Ein Team pinnt die Version jedes Moduls und entscheidet, wann es upgradet. Siehe Versionierung. |
| Dokumentiert | Die Referenz jedes Moduls (Parameter, Outputs) wird aus dem Code generiert. Siehe Release und Dokumentation. |
| Terraform und Bicep | Beide Technologien leben in einem Repository und einem Produkt, in getrennten Ordnern. |
| Gepflegt | Die Bibliothek wird bei jeder Änderung und nach einem wöchentlichen Zeitplan getestet, und die Module werden aktualisiert, wenn sich die Baselines oder die Upstream-Module ändern. |
Wer macht was¶
Die Bibliothek hat ein pflegendes Team und nutzende Teams. Wer welche Rolle übernimmt, hängt vom Betriebsmodell deiner Plattform ab (Betriebsmodelle).
| Rolle | Mit managed-service-Vertrag | Im Eigenbetrieb |
|---|---|---|
| Pflegendes Team: baut, testet, versioniert und released die Module und liefert sie an die Nutzer | XMMS | Das Team des Kunden, dem die Bibliothek gehört |
| XMT Ambassador: richtet Zugriff und onboarding auf der Nutzerseite ein und ist der erste Kontakt bei Fragen | Eine Person des Kunden | Eine Person des Plattform-Teams des Kunden |
| Workload-Team: ruft die Module in seinem eigenen Code auf, pinnt Versionen, deployt über eine pipeline | Das Workload-Team | Das Workload-Team |
Das Workload-Team bleibt für seinen eigenen Infrastrukturcode und dessen Deployment verantwortlich. Ein Modul verringert den Aufwand mit Policies, ist aber keine Garantie, dass ein workload konform ist (Verantwortlichkeiten).
Was in diesem Abschnitt steht¶
| Seite | Inhalt |
|---|---|
| Managed Templates nutzen | Ein Modul referenzieren, Zugriff in einer pipeline erhalten, Versionen wählen und upgraden |
| Modulkatalog | Alle Module nach Service, mit dem, was sie deployen, und ob es sie in Terraform und Bicep gibt |
| IaC Accelerator | Das kopierfertige Beispielprojekt mit Struktur, pipeline und automatisierten Dependency-Updates |
| Policy-Compliance | Wie Module Policies durchsetzen und welche Findings du in Azure Policy trotzdem noch siehst |
| Zugriff einrichten (XMT Ambassador) | Das einmalige Setup und die Zugriffsverwaltung auf der Nutzerseite |
| Repository-Struktur | Die Ordner des Repositorys und was jeder enthält |
| Testing | Der Testansatz: Integrationstests, Azure-Policy-Compliance, gemeinsame Ressourcen |
| Pipelines und Skripte | Die pipelines und die Hilfsskripte des Repositorys |
| Versionierung | Semantic Versioning auf Modulebene, das Changelog und Upgrade-Hinweise |
| Release und Dokumentation | Release-Prozess, generierte Dokumentation, Auslieferung an Nutzer |
| Module erstellen und beitragen | Ein neues Modul erstellen, Fixes an Upstream-Modulen, Leitfaden zum Beitragen |
| Zusammenfassungen der Entscheidungen | Die Entscheidungen hinter dem Design, kurz gefasst |
Wie es zur Plattform passt¶
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)"]Die Module setzen die Baseline eines spokes voraus: private Konnektivität, die Policies auf den management groups und die gemeinsamen Ressourcen. Sie sind ein Weg, konform zu sein, kein Weg an den Policies vorbei. Eine Ressource, die ein Modul nicht konform erstellen kann, ist ein Grund, das Modul zu erweitern oder eine Ausnahme zu beantragen (Policy-Ausnahmen).