DevOps mit OpenShift: die Rolle des Cloud-Host

1 Die Rolle: wissen, tun, betreiben

Der Cloud-Host ist nicht das App-Team. Er baut und betreibt die Plattform, auf der Anwendungen laufen – die Anwendung selbst (hier: die Referenz-App Bibliothek-Enterprise, im Namespace library) bleibt eine eigene Baustelle.

• Wissen ohne Tun bleibt Theorie – deshalb verlinkt jeder Wissenspunkt unten auf eine Hands-on-Anleitung, nicht nur auf eine Definition
• Tun ohne Betreiben ist ein einmaliger Erfolg, der beim nächsten Vorfall wieder bei null anfängt – deshalb Kapitel 5 als eigener Abschnitt
• diese Sammlung deckt alle drei Ebenen bereits ab, nur verstreut über knapp 30 OpenShift-Anleitungen – diese Seite ist die Landkarte dazu

2 Wissenskatalog

Acht Wissensblöcke, jeder mit der Anleitung, die ihn hands-on zeigt. Reihenfolge wie im OpenShift-Atlas: A vor B vor C, weil SCC ServiceAccounts braucht und GitOps Operatoren.

Drei weitere Blöcke aus dem OpenShift-Atlas sind angehängte Themen, kein Pflichtfundament, aber jeweils ihre eigene Anleitung wert: der Umbau eines Legacy-Bestands (Legacy-Modernisierung), der Umgang mit kommerzieller Middleware neben OpenShift (Middleware) und ein SPA-Frontend als eigener Workload-Typ (SPA-Frontend).

3 Tätigkeitskatalog

Das ist der wiederkehrende Teil – nicht der einmalige Cluster-Aufbau, sondern das, was ein neues Team oder ein neuer Dienst jedes Mal wieder auslöst.

1. Namespace/Project anlegen mit Quota, LimitRange und RBAC – siehe Project/oc/ServiceAccount.
2. Netzwerkgrenzen setzen, bevor der erste Pod läuft – Default-Deny plus gezielte Ausnahmen, siehe NetworkPolicy.
3. SCC prüfen und binden – die restriktivste, mit der die Anwendung noch läuft, siehe RBAC/SCC.
4. Build und Rollout einrichten – S2I/BuildConfig für einfache Fälle, Tekton für mehrstufige Pipelines, Argo CD für den eigentlichen Rollout, siehe Build-Kette und GitOps.
5. Zustandsbehaftete Dienste per Operator statt von Hand betreiben, siehe OLM.
6. Monitoring anschließen, bevor der erste Vorfall passiert, siehe Monitoring & Alerting.
7. Node-Wartung planbar machen – Cordon/Drain, MachineConfigPool-Rollout, siehe Logging/MCO/etcd.
8. Backup einrichten, bevor Daten wichtig werden – nicht danach, siehe Backup & Restore.

4 Zusammenspiel im Team

Der Cloud-Host baut die Plattform, das Entwickler-Team baut und betreibt seine Anwendung darauf („you build it, you run it“, Kapitel 1). Bei einer neuen Anwendung treffen sich beide Rollen an denselben acht Schritten aus Kapitel 3 – nur mit unterschiedlichem Anteil. Wer typischerweise was liefert:

4.1 Was das Team vor dem Onboarding liefern sollte

Ein kurzer „Steckbrief“ spart beiden Seiten Rückfragen während des Onboardings:

• Verantwortliche Person/Team und Kontaktweg
• erwarteter Ressourcenbedarf und erwarteter Traffic
• externe Abhängigkeiten (andere Dienste, Drittsysteme, Datenbanken)
• Datenklassifizierung – liegen personenbezogene oder sonst sensible Daten vor
• RPO/RTO-Erwartung (wie viel Datenverlust bzw. Ausfallzeit im Ernstfall tolerierbar ist)
• wer im Ernstfall für die Anwendung erreichbar ist

4.2 Wer im Ernstfall zuständig ist

Die Aufteilung gilt auch im Vorfall: der Cloud-Host ist für Plattform-Vorfälle zuständig (Node down, Cluster-Operator degraded, Router ausgefallen), das Entwickler-Team für Anwendungs-Vorfälle (eigener Dienst wirft Fehler, eigene Datenbank inkonsistent). Ein Alarm, der nicht klar zugeordnet werden kann, geht zuerst an den Cloud-Host – er kennt die Plattform-Symptome und kann schnell ausschließen oder weiterleiten. Der Disaster-Runbook zeigt die Triage dafür.

5 Dauerbetrieb

Was aus „Tun“ einen Dauerzustand macht, statt eines einmaligen Erfolgs.

Die einzelnen Flächen sind unabhängige Anleitungen, weil sie unabhängig versagen können: Monitoring kann grün sein, während das letzte Backup nie getestet wurde. Deshalb gehört eine eigene Zeile pro Fläche in jede Betriebs-Checkliste (Kapitel 7), nicht ein pauschales „läuft“.

6 Durchgängiges Beispiel

Sechs Stationen, ein Namespace – library, das echte Bibliothek-Enterprise-Projekt dieser Sammlung, nicht ein erfundener Beispieldienst. Jede Station zeigt das Kern-Manifest, sagt ehrlich, was davon bereits real läuft und was ein allgemeines OpenShift-Muster ist, und verlinkt die Anleitung mit dem vollständigen Hands-on.

6.1 Build – Quellcode wird Image

Real läuft der Bibliothek-Build heute außerhalb des Clusters: ein Jenkinsfile baut die 9 Images (die Spring-Dienste samt config-server und das Frontend) mit podman build und schiebt sie per podman push in OKDs interne Registry, Pfad library/catalog-service:<git-sha>. Im Cluster gibt es dadurch keinen BuildConfig und keinen Build-Pod, der Cluster-CPU verbraucht – siehe Bibliothek-Enterprise via Jenkins auf OKD.

Das OpenShift-native Gegenstück heißt S2I (Source-to-Image): der Cluster baut aus dem Git-Repository selbst ein Image, ohne dass der Dienst ein eigenes Dockerfile pflegt. Bibliothek nutzt es bewusst nicht, das Muster selbst zeigt S2I bis Rollout an einer kleinen Node.js-Quelle im selben Namespace:

oc new-app https://github.com/sclorg/nodejs-ex -n library --name=demo-build
oc start-build demo-build --follow
oc get istag -n library

6.2 Aussetzen – Service, Route, Probes

Erreichbarkeit intern über den Service (die stabile interne Adresse für Pods, unabhängig von deren wechselnden IPs), extern über die Route (OpenShifts Objekt für Layer-7-Zugriff von außen, vergleichbar mit einem Kubernetes-Ingress), Gesundheit über Readiness- und Liveness-Probes. Details, Fallen bei Probe-Timing: Service/Route/Probes.

6.3 Ausliefern – GitOps statt oc apply von Hand

GitOps heißt: Git ist die einzige Wahrheit, nicht der jeweils letzte Befehl auf dem Cluster. Argo CD (bei OpenShift als „OpenShift GitOps“-Operator installiert) gleicht den Cluster laufend an ein Git-Repository an, eine manuelle Änderung am Cluster wird bei selfHeal automatisch zurückgesetzt. Das reale Beispiel dieses Projekts heißt demo-gitops und zeigt bewusst noch auf ein öffentliches Beispiel-Repository statt auf die Bibliothek selbst – voller Aufbau inklusive Tekton-Pipeline davor: GitOps, Tekton.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-gitops
  namespace: openshift-gitops
spec:
  project: default
  source:
    repoURL: https://github.com/openshift/origin.git
    targetRevision: HEAD
    path: examples/hello-openshift
  destination:
    server: https://kubernetes.default.svc
    namespace: library
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

6.4 Operatoren – wo Bibliothek heute steht

Ehrlich statt schöngeredet: Bibliothek betreibt seine zustandsbehafteten Infra-Dienste (Datenbank, Kafka) heute über Bitnami-Helm-Charts, nicht über einen Operator (einen im Cluster laufenden Controller, der eine Software eigenständig installiert, aktualisiert und bei Fehlern repariert). Der erste echte Operator-Kandidat des Projekts ist der bereits erwähnte OpenShift-GitOps-Operator selbst – er kommt über OLM (den Operator Lifecycle Manager, der Kataloge, Freigaben und Upgrades von Operatoren verwaltet). Der volle Weg vom Katalog bis zur laufenden ClusterServiceVersion, hands-on an genau diesem Operator: OLM. Unabhängig von Helm oder Operator braucht die Datenbank in beiden Fällen dieselbe Grundlage: eine PersistentVolumeClaim, sonst sind ihre Daten beim nächsten Pod-Neustart weg. Die dazugehörige Falle (WaitForFirstConsumer – die StorageClass bindet den Speicher erst, wenn der Pod feststeht) zeigt Cluster-Betrieb.

oc get packagemanifests -n openshift-marketplace | grep -i gitops
oc get csv -n openshift-gitops-operator

6.5 Absichern – Netzwerkgrenzen und Secrets

Default-Deny zuerst (kein Pod im Namespace darf etwas empfangen oder senden), dann gezielte Ausnahmen zwischen den Diensten desselben Namespace. Geheimnisse kommen nicht von Hand in ein Secret (Kubernetes-Objekt für sensible Werte, nur Base64-kodiert, kein Ersatz für echten Zugriffsschutz), sondern über einen kontrollierten Fluss: NetworkPolicy, Secrets.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: library
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

6.6 Beobachten und sichern

Ohne Monitoring wird ein Ausfall erst durch eine Nutzermeldung sichtbar, ohne getesteten Restore ist ein Backup ein unbewiesenes Versprechen. Beide Enden sind eigene Anleitungen: Monitoring & Alerting, Backup & Restore, im Ernstfall Disaster-Runbook.

7 Checklisten

Zum Abhaken, nicht zum Lesen. Jede Zeile zeigt auf die Anleitung, die den Befehl oder den Hintergrund liefert.

7.1 Einstieg für einen neuen Cloud-Host

• [ ] oc-Zugriff, Konsole und GitOps-Repository eingerichtet
• [ ] Fundament verstanden: Project/oc/ServiceAccount, RBAC/SCC
• [ ] einmal eine Restore-Übung begleitet, nicht nur gelesen
• [ ] Zugriff auf Monitoring und Alarme (Monitoring & Alerting)

7.2 Täglich

• [ ] offene kritische Alarme durchgesehen
• [ ] oc get clusterversion und oc get co auf Degraded geprüft
• [ ] Backup-Job der letzten Nacht geprüft (Backup & Restore)

7.3 Wöchentlich

• [ ] Node-Kapazität und Trend geprüft
• [ ] Zertifikats-Ablaufdaten geprüft
• [ ] offene Onboarding-Anfragen abgearbeitet (Kapitel 3)

7.4 Monatlich

• [ ] Kosten gegen Kosten & Budget geprüft
• [ ] eine Restore- oder Failover-Übung durchgeführt (Disaster-Runbook)
• [ ] Server-Härtung erneut gegen Server-Hardening geprüft

7.5 Vor jedem neuen Dienst

• [ ] Default-Deny-NetworkPolicy gesetzt, Ausnahmen dokumentiert
• [ ] SCC ist die restriktivste, mit der der Dienst noch läuft (RBAC/SCC)
• [ ] Secrets kommen aus dem kontrollierten Fluss, nicht von Hand (Secrets)
• [ ] Build- und Rollout-Weg steht (Build-Kette, GitOps)