Terraform + GitHub Actions

Ziel und Umfang

Diese Implementierung soll die gemeinsame AKS-Anwendungsumgebung mit Terraform + GitHub Actions 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 Umgebungskonfiguration

Das geplante Repository trennt Anwendungscode, Kubernetes-Manifeste, Terraform-Module, Umgebungskonfiguration und GitHub-Actions-Workflows. Module beschreiben AKS, Registry und unterstützende Monitoringressourcen. Die DEV- und TEST-Konfiguration wählt Namen, Region, Größen und Zielumgebung.

Remote-State soll in einem eigenen Azure-Storage-Backend mit State-Locking liegen. Jedes Ziel erhält einen eigenen State-Key und eigene Ressourcen. Bootstrap, Zugriffsschutz, Wiederherstellung und späteres Entfernen des Backends werden dokumentiert. State kann sensible Werte enthalten und wird weder in Git eingecheckt noch als Portfolionachweis veröffentlicht.

Diese Implementierung besitzt andere Ressourcengruppen, Identitäten und Ressourcennamen als die Bicep-Variante. Beide Werkzeuge verwalten niemals dieselbe Ressource.

GitHub-Actions-Workflowstufen

Code und Workflows liegen künftig im eigenen öffentlichen GitHub-Repository dieser Implementierung. Vorgeschlagener Ablauf, der während der Umsetzung verfeinert wird:

1. Infrastruktur validieren — Formatierung und Terraform-Konfiguration prüfen.
2. Änderungen planen — Plan für das gewählte Ziel erzeugen und Auswirkungen prüfen.
3. Apply freigeben — ausdrückliche Deploymententscheidung zur geprüften Revision treffen.
4. Infrastruktur anwenden — geprüften Plan mit State-Locking und kontrollierter Parallelität anwenden.
5. Anwendung testen und bauen — Tests ausführen und versioniertes Containerimage bauen.
6. Image veröffentlichen — Image nach ACR übertragen.
7. Anwendung bereitstellen — diese Imageversion auf Kubernetes deployen.
8. Prüfen — Bereitschaft abwarten und Smoke-Test ausführen.

Vorgesehen sind ein geprüfter Plan und ein bewusst autorisiertes Apply. Ob Umgebungsfreigaben und Repository-Schutzfunktionen verfügbar sind, wird anhand der späteren Repository- und Kontokonfiguration geprüft. Weder kostenpflichtige Funktionen noch bestehende Freigabegates werden vorausgesetzt. Planartefakte werden als sensibel behandelt; gleichzeitige Schreibzugriffe auf ein Ziel werden verhindert.

Authentifizierung und Berechtigungen

Geplant ist GitHub-Actions-OIDC-Föderation mit Microsoft Entra ID zur Azure-Authentifizierung. Die Vertrauensbeziehung wird auf das vorgesehene Repository und den Deploymentkontext beschränkt. Workflows erhalten nur benötigte Token- und Repository-Berechtigungen. Infrastrukturzugriff, ACR-Veröffentlichung und Kubernetes-Autorisierung werden getrennt geprüft.

Remote-State-Backend und föderierte Identität benötigen einen ausdrücklichen Bootstrap-Schritt. Ich werde dokumentieren, wer ihn ausführt und welche Berechtigungen danach bleiben. Dauerhafte Azure-Client-Secrets sind nicht als regulärer Authentifizierungsmechanismus vorgesehen.

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

Terraform bringt explizite Zustandsverwaltung und einen eigenen Backend-Lebenszyklus mit. GitHub Actions hält Code und Workflowdefinitionen zusammen. Berechtigungsgrenzen, Umgang mit Plänen und Deploymentkontrollen müssen trotzdem bewusst gestaltet werden. Ihre betrieblichen Auswirkungen dokumentiere ich nach der Umsetzung.

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. Das State-Backend muss verfügbar bleiben, solange Terraform verwaltete Ressourcen entfernt. Das Löschen des Backends erfolgt als eigener, bewusster letzter Schritt, nachdem keine andere Umgebung mehr davon abhängt.

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