Bicep + Azure DevOps

Ziel und Umfang

Diese Implementierung soll die gemeinsame AKS-Anwendungsumgebung mit Bicep + Azure DevOps bereitstellen. Sie ist geplant, nicht ausgerollt. Anwendung, Abnahmekriterien und Fehlertest entsprechen der anderen Implementierung. Alle laufenden Azure-Ressourcen werden jedoch getrennt verwaltet.

Geplante Umsetzung

Ich beginne mit einer kleinen Anwendung und einem reproduzierbaren Entwicklungsziel. Danach ergänze ich Delivery-Automatisierung, Monitoring und Wiederherstellungsprüfungen. DEV und TEST sind konfigurierbare Ziele. Es muss nur die für die aktuelle Übung benötigte Umgebung laufen.

Infrastrukturstruktur und Umgebungsparameter

Das geplante Repository trennt Anwendungscode, Kubernetes-Manifeste, Bicep-Infrastruktur und Pipelinedefinitionen in eigene Ordner. Bicep-Module beschreiben AKS, Registry und unterstützende Monitoringressourcen. Parameterdateien wählen Namen, Region, Größen und das Ziel DEV oder TEST.

Ressourcen erhalten ein implementierungsspezifisches Namenspräfix und eigene Ressourcengruppen. Diese Implementierung verändert weder Ressourcen noch State der Terraform-Variante. Modulgrenzen und genaue Ordnernamen werden beim ersten funktionierenden Deployment verfeinert.

Azure-DevOps-Pipelinestufen

Der Code und die YAML-Pipelinedefinitionen liegen künftig in einem eigenen öffentlichen GitHub-Repository. Azure DevOps Pipelines wird mit diesem Repository verbunden und führt die Build- und Deploymentpipeline aus.

Vorgeschlagener Ablauf, der während der Umsetzung verfeinert wird:

1. Infrastruktur validieren — Bicep und Parameter prüfen.
2. Änderungen anzeigen — what-if-Ergebnis zur Prüfung erzeugen.
3. Infrastrukturdeployment freigeben — Änderungen erst nach einer ausdrücklichen Entscheidung anwenden.
4. Infrastruktur bereitstellen — geprüfte Konfiguration im gewählten Ziel ausrollen.
5. Anwendung testen und bauen — Tests ausführen und Containerimage bauen.
6. Image veröffentlichen — nachvollziehbare Version nach ACR übertragen.
7. Anwendung bereitstellen — Kubernetes-Workload auf diese Imageversion aktualisieren.
8. Prüfen — Bereitschaft abwarten und Smoke-Test ausführen.

Die Freigabe ist eine geplante Anforderung. Umsetzung und Verfügbarkeit in der späteren Azure-DevOps-Organisation werden vor der Auswahl des Mechanismus geprüft. Ein vorhandenes Gate oder eine kostenpflichtige Funktion wird nicht vorausgesetzt.

Authentifizierung und Berechtigungen

Geplant ist eine Azure-Resource-Manager-Service-Connection mit Workload Identity Federation statt eines gespeicherten Azure-Client-Secrets. Die Vertrauensbeziehung wird auf die vorgesehene Pipelineverbindung begrenzt. Infrastrukturänderungen, Imageveröffentlichung und Kubernetes-Deployment erhalten nur die benötigten Berechtigungen. Azure-Ressourcenberechtigungen und Kubernetes-Autorisierung werden getrennt geprüft.

Die erstmalige Einrichtung von Identität und Rollen wird als Bootstrap-Schritt dokumentiert, getrennt von normalen Anwendungsreleases. Zugangsdaten und Tokens dürfen weder in Pipelinelogs noch in veröffentlichten Nachweisen erscheinen.

Deployment und Rollback

Die Anwendung erhält Readiness- und Liveness-Probes, eine Rolling-Update-Strategie und eindeutig zuordenbare Imageversionen. Ein Release gilt erst nach erfolgreichen Rollout-Prüfungen und Smoke-Test als angenommen. Ein fehlgeschlagener Rollout muss in der Pipeline sichtbar werden.

Der Rollback wählt ausdrücklich das zuvor verifizierte Image oder die Deploymentrevision, stellt diese wieder her und wiederholt den Smoke-Test. Dieser Ablauf wird mit einem absichtlich fehlerhaften Release erprobt. Rolling Updates garantieren keine vollständig fehlerfreien Anfragen. Ein Anwendungsrollback macht keine Datenbankänderungen rückgängig. Automatische Rollbacks werden nicht vorausgesetzt.

Monitoring und Fehlersuche

Geplant sind Anwendungslogs und relevante AKS-/Anwendungsmetriken sowie ein Alarm für das kontrollierte Fehlerszenario. Eine kurze Untersuchungsanleitung verbindet den Alarm mit Pipelineausgabe, Pod-Events, Health Probes und Anwendungslogs. Signal und Schwellenwert werden bei der Umsetzung gewählt und anhand von Nachweisen dokumentiert.

Verifikationsnachweise

Ergebnisse ergänze ich nach der Umsetzung. Die gemeinsamen Abnahmekriterien umfassen Infrastrukturvalidierung und Vorschau, Deployment und Smoke-Test, ein Anwendungsupdate, ein fehlerhaftes Release mit gezielter Wiederherstellung, Monitoring des Fehlers und Aufräumen. Jeder Nachweis soll Umgebung, Coderevision, Pipeline-Lauf und Beobachtung benennen. Screenshots ergänze ich nur für tatsächlich ausgeführte Schritte.

Entscheidungen und Abwägungen

Bicep hält die Infrastrukturdefinition nah an Azure. Beide Repositories auf GitHub lassen sich gemeinsam durchsuchen; die Pipeline dieser Implementierung läuft in Azure DevOps. Die Verbindung zwischen GitHub und Azure DevOps ist eine zusätzliche Integration, die eingerichtet und gepflegt werden muss. Ich werde Berechtigungen, Änderungsprüfung und Fehlersuche im Vergleich zum GitHub-Actions-Workflow der Terraform-Variante dokumentieren.

Im Vordergrund steht eine kleine, erklärbare Umgebung statt einer umfassenden Produktionsplattform. Beide Toolchains werden anhand gleichwertiger Anforderungen bewertet. Schlussfolgerungen folgen den Nachweisen.

Kosten, Grenzen und Aufräumen

Gemessene Kosten liegen noch nicht vor. Laufende AKS-Knoten, Registryspeicher, Netzwerk, Monitoring-Datenaufnahme und gegebenenfalls Pipelinenutzung können Kosten verursachen. Die Implementierung dokumentiert gewählte Größen, Laufzeit, verbleibende Ressourcen und tatsächliche Gebühren, soweit verfügbar.

DEV und TEST werden bei Bedarf erstellt. Das Aufräumen entfernt ausschließlich Ressourcen dieser Implementierung und prüft auf verbleibende Datenträger, öffentliche IPs, Registryimages und Monitoringressourcen. Deploymenthistorie ersetzt keinen Aufräumplan. Das Ressourceninventar legt fest, was entfernt werden muss.

Dies ist ein Portfoliolab, keine Zusage zu Produktionsverfügbarkeit oder Sicherheit. Beobachtete Grenzen und Erkenntnisse werden nach der praktischen Umsetzung ergänzt.