Deployment nach Push auf main überwachen¶
Nach einem Push auf den main-Branch eines Service-Repos startet die vollautomatische
Deployment-Kette. Diese Seite beschreibt Schritt für Schritt, wie der Lauf beobachtet
und bei Bedarf eingegriffen werden kann.
Automatisierter Ablauf
Manuell ist nur der git push. Alle folgenden Schritte – Versionierung, Build,
Registry-Push, Manifest-Update und Rollout – laufen automatisch. Die Überwachung
dient der frühzeitigen Fehlererkennung.
Schritt 1 – Pipeline-Status in OpenCode prüfen¶
Unmittelbar nach dem Push startet GitLab die CI/CD-Pipeline des betroffenen Service-Repos.
Vorgehen:
- Die OpenCode-Gruppe der ODI aufrufen: gitlab.opencode.de/sh/zit/opendata/open-data-infrastruktur
- Das gewünschte Service-Repository öffnen (z. B.
odi-ckan-service). - Im linken Menü Build → Pipelines wählen.
- Die neueste Pipeline in der Liste anklicken – ihr Status zeigt sofort den aktuellen Stand:
| Symbol / Status | Bedeutung |
|---|---|
| 🔵 running | Pipeline läuft gerade. |
| ✅ passed | Alle Stufen erfolgreich – Image wurde gepusht. |
| ❌ failed | Mindestens eine Stufe ist fehlgeschlagen. |
| ⏸ pending | Pipeline wartet auf einen freien Runner. |
Bei einem failed-Status den Job-Log öffnen (Klick auf den roten Job-Namen)
und die Fehlermeldung auswerten.
Schritt 2 – Rollout-Status in Headlamp prüfen¶
Nachdem die Pipeline erfolgreich durchgelaufen ist und Flux das neue Image erkannt sowie das Manifest aktualisiert hat, rollt der Cluster den neuen Stand aus. Den aktuellen Zustand zeigt Headlamp – ein webbasiertes Kubernetes-Dashboard.
| Umgebung | Headlamp-URL |
|---|---|
| Stage | headlamp.odi-stage.schleswig-holstein.de |
| Produktion | headlamp.odi.schleswig-holstein.de |
Headlamp der gewünschten Umgebung im Browser öffnen und einloggen. Danach stehen drei Wege zur Verfügung:
a) Flux → Kustomizations¶
- Im linken Menü den Bereich Flux aufklappen.
- Den Eintrag Kustomizations wählen.
- In der Übersicht muss der Fortschrittsbalken bzw. die Prozentzahl 100 % anzeigen. Alle Kustomizations sollen den Status Ready haben.
Alles in Ordnung
Zeigen alle Kustomizations 100 % und den Status Ready, ist der Rollout abgeschlossen und die neue Version läuft im Cluster.
Wert unter 100 % oder Status nicht Ready
Der Rollout ist noch nicht abgeschlossen oder es liegt ein Fehler vor. Die jeweilige Kustomization anklicken und im Reiter Events bzw. Conditions die Fehlermeldung auswerten. Häufige Ursachen sind ein noch laufender Image-Scan durch Flux oder ein fehlgeschlagenes Manifest-Apply.
b) Clusters – Suche nach Service¶
- Im linken Menü Clusters aufklappen.
- Das 🔍-Lupen-Symbol (Suchfeld) anklicken und den Namen des betreffenden
Services eingeben (z. B.
odi-ckan-service). - Die gefilterten Einträge (Pods, Deployments, ReplicaSets) auswerten:
- Deployments zeigen, ob das neue Image bereits referenziert wird.
- Pods zeigen den aktuellen Start-/Laufzustand (
Running,CrashLoopBackOffetc.). - Bei auffälligen Pods den Reiter Logs öffnen, um Laufzeitfehler zu erkennen.
c) Workloads → Pods¶
- Im linken Menü Workloads → Pods wählen.
- Den Pod des betreffenden Services in der Liste anklicken.
- Folgende Angaben prüfen:
- Laufzeit – zeigt, seit wann der Pod läuft; ein frisch gestarteter Pod weist auf einen erfolgreichen Rollout hin.
- Image-Version – im Reiter Details ist das aktuell verwendete Container-Image mit Tag sichtbar; dieser sollte der neu gebauten Version entsprechen.
Schritt 3 – Applikation in der Umgebung prüfen¶
Sind Pipeline und Rollout erfolgreich abgeschlossen, wird der Service direkt in der betroffenen Umgebung aufgerufen und auf korrekte Funktion geprüft.
| Umgebung | Basis-URL |
|---|---|
| Stage | *.odi-stage.schleswig-holstein.de |
| Produktion | *.odi.schleswig-holstein.de |
Vorgehen: 1. Grundlegende Funktionen stichprobenartig testen (Smoke-Test): - Ist die Oberfläche erreichbar und lädt fehlerfrei? - Liefert die API auf bekannte Endpunkte die erwarteten Antworten? - Gibt es sichtbare Fehler, leere Seiten oder HTTP-Fehlercodes (5xx)? 3. Bei Auffälligkeiten die Pod-Logs in Headlamp (siehe Schritt 2) zur weiteren Analyse heranziehen.
Deployment abgeschlossen
Ist die Applikation in der Zielumgebung erreichbar und verhält sich wie erwartet, ist der Deployment-Lauf erfolgreich abgeschlossen.