Seminar Cloud&Heat Titan / SecuStack – Automatisierung mit API, CLI und Infrastructure as Code

Inhaltsübersicht

• Seminarprofil
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxislabor
• Methoden und Arbeitsweise

Seminarprofil

Das Seminar überführt wiederkehrende OpenStack-Aufgaben in kontrollierte, reproduzierbare Automatisierung. Behandelt werden API- und CLI-Nutzung, Terraform, Ansible, Pipeline-Prüfungen, Secret-Schutz, Drift-Erkennung und formalisierte Changes.

Lernziele

• geeignete Automatisierungskandidaten anhand von Risiko und Wiederholbarkeit auswählen
• OpenStack-Abfragen und Änderungen robust über CLI und API ausführen
• wiederverwendbare Terraform- und Ansible-Strukturen aufbauen
• Infrastrukturänderungen mit CI/CD-Prüfungen und Freigaben absichern
• Secrets, State, Drift und manuelle Ausnahmen kontrolliert behandeln

Zielgruppe und Voraussetzungen

Zielgruppe: Cloud- und Plattformadministration, DevOps, Site Reliability Engineering, Automatisierung, technische Anwendungsbetreuung und Infrastrukturentwicklung.

Voraussetzungen: Sicherer Umgang mit Linux-Shell und Versionsverwaltung. Grundkenntnisse in OpenStack-Ressourcen und mindestens einer Skript- oder Automatisierungssprache.

Seminarinhalte

Tag 1: Automatisierungsgrundlagen und OpenStack-Schnittstellen

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Automatisierungsmodell und Wiederholbarkeit

Automatisierung beginnt mit stabilen Standards, eindeutigen Eingaben, idempotenten Abläufen und überprüfbaren Ergebnissen.

1. Schritt 1 – Prozess auswählen: Häufigkeit, Fehleranfälligkeit, Standardisierbarkeit und Sicherheitswirkung bestimmen geeignete Automatisierungskandidaten.
2. Schritt 2 – Sollzustand definieren: Eingaben, Ressourcenmodell, Namenskonventionen, Abhängigkeiten und erwartete Ergebnisse werden formal beschrieben.
3. Schritt 3 – Idempotenz sicherstellen: Wiederholte Ausführung führt zum gleichen Zustand und erzeugt keine unkontrollierten Duplikate.
4. Schritt 4 – Kontrollen einbauen: Validierung, Dry Run, Logging, Fehlerbehandlung, Rollback und Freigabe werden Teil des Ablaufs.

Praxisbezug: Bewertung mehrerer Betriebsaufgaben und Auswahl eines geeigneten Automatisierungskandidaten.

OpenStack-API und CLI für Automatisierung

API und CLI liefern reproduzierbare Schnittstellen für Inventarisierung, Bereitstellung und kontrollierte Massenänderungen.

1. Schritt 1 – Authentifizierung kapseln: clouds.yaml, Application Credentials und Zertifikatsprüfung werden ohne Klartextgeheimnisse eingebunden.
2. Schritt 2 – Abfragen stabilisieren: Filter, maschinenlesbare Ausgabe, Pagination und eindeutige IDs werden statt bildschirmorientierter Ausgabe verwendet.
3. Schritt 3 – Änderungen absichern: Vorprüfung, Zielmengenermittlung, Bestätigung, Fehlercode und Wiederholungslogik werden implementiert.
4. Schritt 4 – Ergebnisse protokollieren: Request-ID, Objekt-ID, Zeit, Aktion und Status werden für Audit und Fehleranalyse gespeichert.

Praxisbezug: Erstellung eines robusten CLI-Ablaufs zur Inventarisierung und Quotenprüfung mehrerer Projekte.

Bedienung über Horizon, CLI und API

Grafische Oberfläche, Kommandozeile und API werden als komplementäre Werkzeuge für Bedienung, Automatisierung und Fehleranalyse eingesetzt.

1. Schritt 1 – Zugang konfigurieren: Projektkontext, Anmeldeverfahren, OpenRC-Datei beziehungsweise clouds.yaml und Zertifikatsprüfung werden kontrolliert eingerichtet.
2. Schritt 2 – Ressourcen anzeigen: Dienste, Endpunkte, Quoten, Netzwerke, Images, Flavors und Instanzen werden zunächst lesend inventarisiert.
3. Schritt 3 – Änderungen durchführen: Ressourcen werden über Horizon und CLI angelegt, geändert und gelöscht; Unterschiede in Rückmeldung und Nachvollziehbarkeit werden bewertet.
4. Schritt 4 – API-Antworten prüfen: Request-ID, Statuscode, Fehlertext und Zeitstempel werden für spätere Korrelation mit Plattformprotokollen gesichert.

Praxisbezug: Bereitstellung derselben Testressourcen über Horizon und CLI mit Vergleich der erzeugten Objekte.

Tag 2: Infrastructure as Code und Pipeline-Qualität

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Infrastructure as Code mit Terraform und Ansible

Terraform modelliert Cloud-Ressourcen deklarativ; Ansible ergänzt Konfiguration und orchestrierte Betriebsschritte.

1. Schritt 1 – Verantwortung trennen: Cloud-Ressourcen, Gastkonfiguration und Plattformbetrieb werden klar auf Werkzeuge und Repositories verteilt.
2. Schritt 2 – State absichern: Terraform-State, Sperre, Verschlüsselung, Zugriff und Sicherung werden als kritische Betriebsdaten behandelt.
3. Schritt 3 – Module entwickeln: Netze, Sicherheitsgruppen, Instanzen und Volumes werden mit validierten Eingaben und sinnvollen Standardwerten gekapselt.
4. Schritt 4 – Änderung prüfen: Formatierung, Validierung, Plan, Peer Review, Freigabe und kontrolliertes Apply bilden die feste Kette.

Praxisbezug: Aufbau eines kleinen IaC-Moduls für Netzwerk, Sicherheitsgruppe und Testinstanz.

CI/CD für Infrastrukturänderungen

Pipelines automatisieren Qualitätskontrollen und halten produktive Änderungen an nachvollziehbare Freigaben gebunden.

1. Schritt 1 – Pipeline-Stufen definieren: Linting, Syntaxprüfung, Sicherheitsprüfung, Plan, Review, Freigabe und Ausführung werden getrennt.
2. Schritt 2 – Credentials begrenzen: Kurzlebige Zugangsdaten, getrennte Umgebungen und minimal berechtigte Servicekonten reduzieren das Pipeline-Risiko.
3. Schritt 3 – Artefakte sichern: Pläne, Prüfberichte, Logs und Freigabeinformationen werden versioniert und vor Manipulation geschützt.
4. Schritt 4 – Fehlerpfad testen: Abbruch, Teilfehler, Wiederholung und manuelle Wiederaufnahme werden vor Produktiveinsatz erprobt.

Praxisbezug: Entwurf einer Pipeline für Terraform-Änderungen mit manueller Produktionsfreigabe.

Governance, Review und Drift-Erkennung

Automatisierter Betrieb bleibt nur kontrollierbar, wenn Quellcode, realer Zustand und genehmigte Baseline regelmäßig abgeglichen werden.

1. Schritt 1 – Repository-Regeln festlegen: Branch-Schutz, Review-Pflicht, Signierung, Eigentümer und Freigaberegeln werden definiert.
2. Schritt 2 – Policy-Prüfungen integrieren: Namenskonventionen, Netzwerkfreigaben, Imagequellen, Verschlüsselung und Quoten werden automatisiert geprüft.
3. Schritt 3 – Drift erkennen: Manuelle Änderungen und Abweichungen zwischen Code, State und Plattform werden regelmäßig gemeldet.
4. Schritt 4 – Drift behandeln: Übernahme, Rückführung oder genehmigte Ausnahme werden mit Verantwortlichkeit und Frist dokumentiert.

Praxisbezug: Entwicklung einer einfachen Policy- und Drift-Checkliste für ein IaC-Repository.

Tag 3: Secrets, Changes und technische Validierung

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Konfiguration, Secrets und Zertifikate

Konfigurationsdaten, Geheimnisse und Zertifikate werden getrennt, versioniert und mit minimalem Zugriff verwaltet.

1. Schritt 1 – Daten klassifizieren: Öffentliche Konfiguration, vertrauliche Parameter, Passwörter, Schlüssel und Zertifikate werden eindeutig unterschieden.
2. Schritt 2 – Ablage festlegen: ConfigMaps, Kubernetes-Secrets, externe Schlüsselverwaltung und verschlüsselte Repositories werden nach Schutzbedarf gewählt.
3. Schritt 3 – Rotation planen: Gültigkeit, Erneuerung, Abhängigkeiten, Rollout und Rückfall werden für Zertifikate und Zugangsdaten festgelegt.
4. Schritt 4 – Verwendung prüfen: Mounts, Umgebungsvariablen, Dateirechte und unbeabsichtigte Ausgabe in Logs werden kontrolliert.

Praxisbezug: Planung einer Zertifikatsrotation mit betroffenen Diensten, Reihenfolge und Prüfschritten.

Change Management und Wartungsfenster

Technische Änderungen werden mit Risiko, Abhängigkeit, Kommunikationsplan, Freigabe und Rückfall steuerbar gemacht.

1. Schritt 1 – Änderung beschreiben: Zweck, Umfang, betroffene Dienste, erwarteter Nutzen und Nicht-Ziele werden präzise festgehalten.
2. Schritt 2 – Risiko analysieren: Fehlerdomäne, Kundenauswirkung, Datenrisiko, Paralleländerungen und fehlende Tests werden bewertet.
3. Schritt 3 – Durchführung vorbereiten: Schritte, Rollen, Zeitplan, Monitoring, Abbruchkriterien und Rückfall werden verbindlich dokumentiert.
4. Schritt 4 – Abschluss bewerten: Funktion, Nebenwirkungen, Monitoring, Dokumentation und gegebenenfalls Nacharbeit werden bestätigt.

Praxisbezug: Erstellung eines Standard-Changes und eines risikoreichen Normal-Changes für eine Plattformkomponente.

Pilotierung und technische Validierung

Ein Pilot reduziert Unsicherheit, wenn repräsentative Workloads, Betriebsverfahren und Sicherheitskontrollen getestet werden.

1. Schritt 1 – Pilotumfang festlegen: Workload, Datenklasse, Nutzergruppe, Integrationen und Erfolgskriterien werden begrenzt und repräsentativ gewählt.
2. Schritt 2 – Testfälle ableiten: Funktion, Leistung, Ausfall, Backup, Sicherheit, Monitoring und Betrieb werden in konkrete Tests übersetzt.
3. Schritt 3 – Ergebnisse messen: Messwerte, Abweichungen, Bedienaufwand und notwendige Anpassungen werden nachvollziehbar dokumentiert.
4. Schritt 4 – Produktionsfreigabe entscheiden: Erfüllte Kriterien, Restpunkte, Risiken und Bedingungen werden in eine belastbare Freigabeentscheidung überführt.

Praxisbezug: Entwicklung eines Pilotplans für eine repräsentative Anwendung.

Praxislabor

• Bewertung mehrerer Betriebsaufgaben und Auswahl eines geeigneten Automatisierungskandidaten.
• Bereitstellung derselben Testressourcen über Horizon und CLI mit Vergleich der erzeugten Objekte.
• Aufbau eines kleinen IaC-Moduls für Netzwerk, Sicherheitsgruppe und Testinstanz.
• Entwicklung einer einfachen Policy- und Drift-Checkliste für ein IaC-Repository.
• Planung einer Zertifikatsrotation mit betroffenen Diensten, Reihenfolge und Prüfschritten.
• Entwicklung eines Pilotplans für eine repräsentative Anwendung.

Methoden und Arbeitsweise

Fachliche Einordnung, strukturierte Demonstrationen, geführte Systemübungen, technische Prüflisten und dokumentierte Störungsszenarien wechseln sich ab. Jeder Arbeitsschritt wird mit Ausgangszustand, erwarteter Wirkung, Prüfkriterium und Rückfallmöglichkeit beschrieben. Die Übungen verwenden realistische Rollen- und Fehlerbilder; produktive Zugangsdaten oder externe Verbindungen sind nicht erforderlich.