Seminar Aiven Automation – Terraform und Kubernetes Operator

Das Seminar behandelt deklarative Bereitstellung für klassische Infrastructure-as-Code-Umgebungen und für Kubernetes-zentrierte Plattformteams. Der Schwerpunkt liegt auf kontrollierbaren Zuständen statt auf einzelnen Konsolenaktionen.

Inhaltsverzeichnis

1. Einordnung und Nutzen
2. Zielgruppe
3. Voraussetzungen
4. Lernziele
5. Seminarinhalte
6. Tag 1: Terraform-Provider und Zustandsmodell
7. Tag 2: Module, Änderungen und Driftkontrolle
8. Tag 3: Aiven Operator für Kubernetes und GitOps
9. Praxisübungen

Einordnung und Nutzen

Der Aiven Provider für Terraform beziehungsweise OpenTofu und der Aiven Operator für Kubernetes werden von der Initialisierung bis zum produktionsnahen Änderungsprozess eingesetzt. State, Import, Drift, Geheimnisse, Custom Resource Definitions, Reconciliation, GitOps und Fehlerdiagnose werden zusammenhängend bearbeitet.

Zielgruppe

• Cloud- und Plattformadministration
• DevOps- und Site-Reliability-Engineering
• Technische Architektur und Betrieb
• Kubernetes- und GitOps-Verantwortliche
• Infrastructure-as-Code-Entwicklung

Voraussetzungen

• Grundkenntnisse zu Cloud-Diensten, Netzwerken und Datenbanken
• Sicherer Umgang mit Browser und Kommandozeile
• Für Übungen ein freigegebenes Aiven-Projekt oder eine vorbereitete Schulungsumgebung
• Grundkenntnisse in Terraform oder OpenTofu
• Grundkenntnisse zu Kubernetes-Ressourcen und YAML

Lernziele

• Aiven-Ressourcen mit Terraform beziehungsweise OpenTofu deklarativ verwalten
• State, Import und Drift ohne unkontrollierte Neuerstellung beherrschen
• Wiederverwendbare Module mit sicheren Variablen und Outputs entwickeln
• Aiven-Ressourcen über Kubernetes Custom Resources bereitstellen
• Reconciliation, Secrets und GitOps-Änderungen diagnostizieren und absichern

Seminarinhalte

Jeder Arbeitsschritt wird praktisch umgesetzt, mit einem kurzen Funktionstest geprüft und als wiederholbarer Betriebsablauf dokumentiert.

Tag 1: Terraform-Provider und Zustandsmodell

Der erste Tag schafft die Grundlage für reproduzierbare Pläne und sichere Zustandsführung.

1. Schritt 1: Provider, Authentifizierung und Projektstruktur einrichten. Praktisches Arbeitsergebnis: Providerkonfiguration, Tokenübergabe, Versionsbindung und eine getrennte Verzeichnisstruktur für Umgebungen aufgebaut.
2. Schritt 2: Organisation und Projekte modellieren. Praktisches Arbeitsergebnis: Organisationseinheiten, Projekte und grundlegende Metadaten in Ressourcen übersetzt und Abhängigkeiten im Plan nachvollzogen.
3. Schritt 3: Ersten Managed Service bereitstellen. Praktisches Arbeitsergebnis: Cloud, Region, Plan, Serviceparameter und Tags deklariert, der Plan geprüft und die Bereitstellung kontrolliert ausgeführt.
4. Schritt 4: State sicher verwalten. Praktisches Arbeitsergebnis: lokaler und entfernter State verglichen, Sperrung und Zugriffsschutz eingeordnet sowie sensible Werte aus sichtbaren Ausgaben entfernt.
5. Schritt 5: Bestehende Ressourcen importieren. Praktisches Arbeitsergebnis: eine vorhandene Ressource importiert, die Konfiguration an den Istzustand angepasst und eine unbeabsichtigte Ersetzung verhindert.

Tag 2: Module, Änderungen und Driftkontrolle

Der zweite Tag entwickelt aus Einzelressourcen wartbare Plattformbausteine.

1. Schritt 1: Modulgrenzen und Schnittstellen definieren. Praktisches Arbeitsergebnis: ein Servicebaustein mit klaren Eingabevariablen, validierten Werten, Outputs und einheitlichen Tags entworfen.
2. Schritt 2: Benutzer, Integrationen und Netzwerkbezüge ergänzen. Praktisches Arbeitsergebnis: abhängige Ressourcen in definierter Reihenfolge modelliert und sensible Zugangsdaten über geeignete Übergabemechanismen behandelt.
3. Schritt 3: Änderungsfolgen bewerten. Praktisches Arbeitsergebnis: Planänderungen nach In-Place-Update, Rebuild oder Replacement klassifiziert und für risikoreiche Änderungen ein Freigabeschritt eingerichtet.
4. Schritt 4: Drift erkennen und bearbeiten. Praktisches Arbeitsergebnis: eine manuelle Konsolenänderung provoziert, im Plan sichtbar gemacht und wahlweise übernommen oder auf den Sollzustand zurückgeführt.
5. Schritt 5: CI-Prüfstrecke entwerfen. Praktisches Arbeitsergebnis: Formatierung, Validierung, Planartefakt, Vier-Augen-Freigabe und Apply-Protokoll als kontrollierte Pipeline beschrieben und erprobt.

Tag 3: Aiven Operator für Kubernetes und GitOps

Der dritte Tag überträgt das deklarative Modell auf Kubernetes und den Reconciliation-Prozess.

1. Schritt 1: Operator und Berechtigungen vorbereiten. Praktisches Arbeitsergebnis: Namespace, Operatorinstallation, Aiven-Token als Secret und die erforderlichen Kubernetes-Berechtigungen kontrolliert eingerichtet.
2. Schritt 2: Custom Resources anwenden. Praktisches Arbeitsergebnis: Projekt- und Serviceressourcen als YAML beschrieben, angewendet und über Statusfelder sowie Ereignisse bis zum Zielzustand verfolgt.
3. Schritt 3: Secrets und Verbindungsdaten verwalten. Praktisches Arbeitsergebnis: generierte Zugangsdaten in Kubernetes referenziert, Zugriffsrechte begrenzt und eine Rotation ohne Ablage im Git-Repository vorbereitet.
4. Schritt 4: Reconciliation und Fehler untersuchen. Praktisches Arbeitsergebnis: absichtliche Schema-, Berechtigungs- und Konfigurationsfehler anhand von Events, Conditions und Operator-Logs diagnostiziert.
5. Schritt 5: GitOps-Betriebsmodell festlegen. Praktisches Arbeitsergebnis: Repository-Struktur, Pull-Request-Prüfungen, Umgebungsfreigaben, Löschschutz und Verantwortlichkeiten für Terraform und Operator voneinander abgegrenzt.

Praxisübungen

• Bereitstellung eines Aiven-Projekts und eines Datenbankservices aus einem Terraform-Modul
• Import einer bestehenden Ressource ohne Serviceunterbrechung
• Driftanalyse nach einer kontrollierten manuellen Änderung
• Bereitstellung eines Services über eine Kubernetes Custom Resource
• Fehlerdiagnose bei fehlendem Secret und ungültiger Ressourcenkonfiguration