AKS-Delivery mit Bicep und Terraform
Eine geplante AKS-Anwendungsumgebung, umgesetzt mit Bicep und Azure DevOps oder Terraform und GitHub Actions.
Auf dieser Seite
Bicep: GitHub → Azure DevOps Pipelines. Terraform: GitHub → GitHub Actions. Azure-Ressourcen, Identitäten und Konfigurationen bleiben getrennt.
Problem und angestrebtes Ergebnis
Eine Anwendung einmal bereitzustellen ist nur ein Teil der Arbeit. Ich möchte Infrastrukturänderungen nachvollziehbar prüfen, Releases wiederholbar ausführen, Fehler sichtbar machen und die Wiederherstellung ausdrücklich beschreiben.
Geplant ist eine kleine containerisierte Anwendung auf AKS mit Images in Azure Container Registry. Zwei gleichwertige Implementierungen sollen dieselben Anforderungen erfüllen und dieselben Prüfungen bestehen. So lassen sich die Unterschiede zwischen den Toolchains praktisch beobachten.
Zwei Implementierungen, gemeinsame Anforderungen
| Bereich | Bicep + Azure DevOps | Terraform + GitHub Actions |
|---|---|---|
| Quellcode | Eigenes öffentliches GitHub-Repository | Eigenes öffentliches GitHub-Repository |
| Infrastruktur | Bicep-Module und Umgebungsparameter | Terraform-Module und Umgebungskonfiguration |
| Delivery-Pipeline | Azure DevOps Pipelines | GitHub Actions |
| Änderungsprüfung | Validierung und Bicep what-if | Validierung und Terraform plan |
| Zustand | Azure-Ressourcenbereitstellungen; kein Terraform-State | Getrennter Remote-State mit Sperrung |
| Azure-Zugriff | Föderierte Service Connection | Föderierte Workflow-Identität |
| Anwendung und Prüfungen | Gleiche geplante Anwendung und Prüfszenarien | Gleiche geplante Anwendung und Prüfszenarien |
Die Repositories bleiben unabhängig. Sie verwalten niemals dieselben laufenden Azure-Ressourcen. Ressourcennamen, Ressourcengruppen, Identitäten und Konfiguration unterscheiden Implementierung und Zielumgebung. Terraform-State gehört ausschließlich zur Terraform-Implementierung.
DEV und TEST sind konfigurierbare Ziele. Es müssen nicht beide Umgebungen dauerhaft laufen. Ich möchte nur die für eine Prüfsitzung benötigten Ressourcen bereitstellen und anschließend aufräumen.
Geplanter Umfang
- Eine kleine Anwendung, ein Containerimage, AKS und Azure Container Registry.
- Infrastrukturvalidierung, Änderungsvorschau und kontrollierte Bereitstellung.
- Automatisierte Anwendungstests, Image-Build, Veröffentlichung, Deployment und Smoke-Test.
- Föderierte Pipeline-Authentifizierung bei Azure mit begrenzten Berechtigungen.
- Kubernetes-Readiness- und Liveness-Probes, Rolling Updates und ein dokumentierter Rollback.
- Grundlegende Anwendungslogs, Cluster-/Anwendungsmetriken und ein Alarm für ein nützliches Fehlersignal.
- Aufräumanleitung, Ressourceninventar und Kostenbeobachtungen.
Die erste Version wird weder eine Multi-Region-Plattform noch eine vollständige Enterprise Landing Zone. Im Mittelpunkt steht ein kleines System, dessen Bereitstellung und Wiederherstellung erklärbar und reproduzierbar sind.
Geplante Prüfszenarien
Dies sind Abnahmekriterien, keine abgeschlossenen Ergebnisse. Beide Implementierungen verwenden dasselbe Anwendungsverhalten, Releaseszenario und dieselben erwarteten Ergebnisse.
| Szenario | Zu dokumentierender Nachweis |
|---|---|
| Infrastruktur validieren und prüfen | Validierungsausgabe und geprüfte Änderungsvorschau vor dem Deployment |
| Anwendung bereitstellen | Pipeline-Lauf, bereite Pods und erfolgreicher Smoke-Test |
| Anwendung aktualisieren | Neue Imageversion und abgeschlossener Rollout mit erwarteter Antwort |
| Fehlerhaftes Release einführen | Kontrollierter Fehler, Erkennung und dokumentierte Entscheidung zur Wiederherstellung |
| Gezielt wiederherstellen | Ausgeführter Rollback und anschließend erfolgreicher Smoke-Test |
| Fehler beobachten | Relevante Logs und Metriken sowie der durch das gewählte Fehlersignal ausgelöste Alarm |
| Aufräumen | Ressourceninventar vor und nach dem Entfernen, einschließlich verbleibender Ressourcen und State |
Rolling Updates garantieren nicht automatisch unterbrechungsfreien Betrieb. Die Wiederherstellung wird ein ausdrücklicher Ablauf; automatische Rollbacks werden nicht vorausgesetzt. Der Fehlertest bleibt auf die entbehrliche Lab-Umgebung begrenzt.
Was der Vergleich zeigen soll
Ich werde Änderungsprüfung, Umgebungskonfiguration, Authentifizierung, fehlgeschlagene Releases und Aufräumen vergleichen. Aussagen über Aufwand, Zuverlässigkeit und Kosten sollen auf dokumentierten Ergebnissen beruhen. Keine Toolchain wird vorab als Sieger dargestellt.