IaC Accelerator¶

Der IaC Accelerator ist ein vollständiges, lauffähiges Beispiel für ein Infrastructure-as-Code-Projekt, das die Module von Managed Templates nutzt. Er ist für Teams gedacht, die neu bei der Bibliothek oder bei Infrastructure as Code sind. Du kopierst ihn in dein eigenes Repository und passt ihn an. Er senkt die Einstiegshürde und gibt dir eine Struktur, eine Deployment-pipeline und automatisierte Updates deiner Modulversionen.

Ein Referenzprojekt, kein Produkt

Der Accelerator zeigt einen empfohlenen Ansatz. Spezialfälle sind nicht sein Ziel: Passe die Dateien an deine Bedürfnisse an. Die Namen, der Pool, die service connections, subscriptions und die Registry in den Dateien sind Platzhalter, die du ersetzen musst. Das pflegende Team testet und unterstützt den Accelerator selbst, nicht die Änderungen, die du an deiner Kopie vornimmst.

Was er enthält¶

Teil	Terraform	Bicep
Projektstruktur	Root module pro Umgebung, ein gemeinsames `main`-module, lokale Module	Eine `main.bicep`, eine Parameterdatei pro Umgebung, lokale Module
Deployment-pipeline	Plan-Stage, dann eine Apply-Stage, die auf Genehmigung wartet	Eine optionale What-if-Stage, dann eine Deploy-Stage, die auf Genehmigung wartet
Automatisierte Updates	Renovate-Konfiguration und pipeline, für Azure DevOps oder GitHub Actions	Dasselbe
Modulquelle	`git::`-Quelle mit einem Versions-tag	Referenz auf eine Container Registry mit einer Version

Was er deployt¶

Der Beispiel-workload besteht aus den folgenden Ressourcen. Es ist eine Auswahl von Modulen, keine empfohlene Architektur.

Ressource	Modul
Ressourcengruppe	Einfache Ressource, mit dem Azure-Naming-module benannt (Terraform)
User-assigned Identity	`user_assigned_identity`
Log-Analytics-Workspace	`log_analytics_workspace`
Key Vault, mit einem Verschlüsselungs-Key	`key_vault`
Storage Account, mit dem Key verschlüsselt	`storage_account`
App Service Plan und eine Linux-Web-App	`serverfarm`, `app_service_site_linux`
Windows-VM	`virtual_machine_windows`
SQL Server	`sql_server`
Recovery Services vault mit einer VM-Backup-Policy	Lokaler Code im Accelerator (`rsv`), kein Bibliotheksmodul

Das Beispiel verbindet sich mit einem vorhandenen spoke: Es schlägt das virtual network und das Subnetz nach und platziert die private endpoints dort. Die Standardnamen folgen der Namenskonvention des spoke canvas (Namen und Tags): Ändere sie, wenn dein spoke andere Namen nutzt. Das heißt, der Accelerator funktioniert am besten in einem spoke, den die Plattform für dich erstellt hat (Was du bekommst).

Struktur¶

Terraform¶

environments/          One root module per environment (dev, prod). Entry point, providers, backend, variables.
main/                  Infrastructure for all environments: resources, module calls, data sources.
modules/               Project-specific modules.
pipelines/             terraform.yaml, templates for plan and apply, Renovate pipeline and workflow.
renovate.json          Example Renovate configuration.

Jedes Verzeichnis in environments/ ist ein Root module, das das gemeinsame main-module mit umgebungsspezifischen Werten aufruft. Du kannst Umgebungen hinzufügen, indem du Verzeichnisse ergänzt. Die Struktur erlaubt es auch, von einer Workstation aus zu deployen, über ein VPN, wenn bei Ressourcen der öffentliche Zugriff deaktiviert ist. Entscheide, ob du die Terraform-Versionsbeschränkungen in main/terraform.tf oder in jeder Umgebung setzt.

Bicep¶

main.bicep             The infrastructure, at subscription scope.
dev.bicepparam         Parameters of the dev environment.
prod.bicepparam        Parameters of the prod environment.
modules/               Local modules: the backup vault, and a module that looks up the spoke network.
pipelines/             bicep.yaml, a single-environment template, Renovate pipeline and workflow.
renovate.json          Example Renovate configuration.

Halte gemeinsame Ressourcen, Namen und Outputs in main.bicep und umgebungsspezifische Werte in den Parameterdateien.

So nutzt du ihn¶

Kopiere den Inhalt von iac_accelerator/terraform/ oder iac_accelerator/bicep/ aus dem Bibliotheks-Repository in dein Repository.
Prüfe und passe alle Dateien an. Suche nach den TODO-Kommentaren und nach der Repository-Adresse (Terraform) oder der Registry- Adresse (Bicep), die die Dateien als Beispiel enthalten. Ersetze sie durch deine.
Passe die pipeline-Definition an dein CI/CD-Setup an: Agent-Pool, Namen der service connections, subscriptions und die Version des Tools (Terraform oder Bicep).
Erstelle Azure-DevOps-Environments, die zu deinen Umgebungsnamen passen (dev, prod), und füge für alle Genehmiger hinzu, damit sich nichts ohne Prüfung des vorherigen Ergebnisses ändert.
Erstelle service connections auf subscription-Ebene.
Stelle sicher, dass die pipeline die Bibliothek lesen kann: siehe Der pipeline Zugriff auf das Repository geben für Terraform und Einer Bicep-pipeline Zugriff geben für Bicep. Die Terraform- pipeline enthält die Git-Schritte bereits.
Committe, pushe, füge die pipeline-Datei in Azure DevOps als pipeline hinzu und führe sie aus.

Werte aus einer Variable Group übergeben¶

	Terraform	Bicep
Wie	Liste die Variable Group im `variables`-Block auf und ordne Werte mit dem Parameter `envs` zu, zum Beispiel `TF_VAR_my_variable: $(variable-group-variable-name)`	Nutze `variableGroupName` für die Gruppe, `secretToEnvMapping` für Secrets und `bicepAdditionalParams` für einfache Werte
Secrets	Markiere sie in der Gruppe als Secret und in Terraform als `sensitive`	Markiere sie in der Gruppe als Secret und ordne sie mit `secretToEnvMapping` zu, damit sie nicht geloggt werden

Werte, die von außen kommen, machen es schwerer, den Code lokal auszuführen: Liefere sie dann auf anderem Weg (Umgebungsvariablen oder eine .tfvars-Datei, die nicht committet wird).

Die pipelines¶

Terraform-pipeline¶

Die pipeline hat die Parameter environment (dev oder prod) und operation (apply oder destroy). Das Template führt zwei Stages aus: eine Plan-Stage und eine Deploy-Stage, die nur läuft, wenn der Plan Änderungen enthält. Die Deploy-Stage nutzt ein Azure-DevOps-Environment, die Genehmiger, die du konfigurierst, müssen sie also genehmigen. Das Apply nutzt den gespeicherten Plan, und nach einem Apply speichert ein Refresh-only-Lauf Nebeneffekte der API im state.

Bicep-pipeline¶

Die pipeline hat Stages für dev und prod, wobei prod von dev abhängt. Jede Stage kann zuerst ein What-if ausführen (der Parameter runWhatIf, standardmäßig aus, weil die Ausgabe verrauscht sein kann) und deployt dann mit az deployment sub create. Die Bicep-Version wird aus einer pipeline-Variable installiert.

Module aktuell halten¶

Der Accelerator enthält ein Renovate-Setup. Renovate prüft die Versionen der Module, die du nutzt (und der Terraform-Provider), und öffnet einen pull request, wenn es eine neuere Version gibt. Es liest die Bicep-Registry- Referenzen und die Terraform-git::-Quellen mit tags der Form terraform/<module>/<version>, pro Modul begrenzt, sodass ein Modul nie eine Version aus den tags eines anderen Moduls bekommt. Updates werden nach Update-Typ gruppiert.

Richte es so ein:

Behalte die pipeline oder den Workflow, der zu deiner Plattform passt (Azure DevOps oder GitHub Actions), und lösche den anderen.
Ersetze die Platzhalter in renovate.json und in der pipeline (die Registry, das Repository, den Agent-Pool).
Gib Renovate die Berechtigung, Branches und pull requests zu erstellen. In Azure DevOps sind das Contribute und Contribute to pull requests für die Build-Identität der pipeline. In GitHub Actions brauchst du eine GitHub App, weil pull requests, die das Standard-Token erstellt, keine anderen Workflows starten.
Gib bei Bicep der pipeline Zugriff auf die Registry über eine service connection, die workload identity federation nutzt. Für Terraform-Module in einem anderen Repository gib auch dort Lesezugriff.
Führe es einmal mit dryRun auf true aus. Der Standard ist false, und der wöchentliche Zeitplan führt es echt aus. Prüfe, dass alle Dateien mit Referenzen im Log erscheinen und dass keine Abhängigkeit einen skipReason hat.
Führe es dann ohne Dry-run aus. Prüfe nach dem ersten echten Lauf, dass ein pull request nur den Versions-String ändert.

Lies das Changelog, bevor du mergst

Ein Renovate-pull-request ändert die Version, nicht deinen Code. Prüfe das Changelog und die Upgrade-Hinweise bei Major-Versionen und lass deine normale pipeline die Änderung zuerst in dev testen.