OpenShift-Manifeste (Migrationsphase M5/M7)

Letzter Schritt der Migration - Deployment des modernen Reactors auf OpenShift, wie von Anfang an geplant ("zuletzt ... auf OpenShift migrieren"). Ersetzt das WebSphere-Liberty- EAR-Deployment (novaris-policy-ear) des Legacy-Reactors.

Dateien und Reihenfolge

oc apply -f namespace.yaml
oc apply -f kafka-cluster.yaml          # braucht den Strimzi-Operator, siehe unten
oc apply -f configmap.yaml
oc apply -f secret-template.yaml        # in echt: aus Jenkins-Credentials generiert, nicht aus dieser Datei
oc apply -f policy-core-deployment.yaml
oc apply -f claims-deployment.yaml
oc apply -f notification-deployment.yaml
oc apply -f frontend-deployment.yaml
oc apply -f availability-and-network.yaml

Datei	Inhalt	Ersetzt (Legacy)
`namespace.yaml`	Projekt/Namespace `novaris-modern`	-
`kafka-cluster.yaml`	Strimzi `Kafka` + drei `KafkaTopic` (Custom Resources)	echtes IBM MQ (Testcontainers, `novaris-integration-tests`)
`configmap.yaml`	nicht-geheime Konfiguration (Kafka-Bootstrap, Billing-Partner-URL, Oracle-JDBC-URL)	`ci/env/*.properties`
`secret-template.yaml`	Platzhalter fuer Oracle-Passwort	Jenkins-Credentials-Store
`policy-core-deployment.yaml`	Deployment (2 Replicas) + Service + Route fuer `novaris-policy-core-modern` (immutable Ausgangstag `1.0.0`)	`novaris-policy-ear` + Liberty-`server.xml`
`claims-deployment.yaml`	Deployment (1 Replica) fuer `novaris-claims-modern`	- (novaris-claims-mq hatte kein eigenes Deployment, war Client-Bibliothek)
`notification-deployment.yaml`	Deployment (1 Replica) fuer `novaris-notification-modern`	-
`frontend-deployment.yaml`	Deployment (2 Replicas) + Service + Route fuer die React-SPA	`novaris-policy-web-legacy-jsf`
`availability-and-network.yaml`	PodDisruptionBudgets und restriktive Ingress-Regeln	neue Betriebs-/Sicherheitsanforderungen

Voraussetzungen

Strimzi-Operator (bzw. dessen Red-Hat-Distribution "Streams for Apache Kafka") muss im Cluster installiert sein, bevor kafka-cluster.yaml etwas bewirkt - die Kafka/KafkaTopic- Ressourcen sind Custom Resources, ohne Operator ignoriert der API-Server sie (kein CRD registriert).
Container-Images muessen in der internen OpenShift-Registry (oder einer anderen, vom Cluster erreichbaren Registry) vorliegen - siehe ../novaris-policy-core-modern/Dockerfile und die OpenShift-Stage in Jenkinsfile (in diesem Verzeichnis).
Oracle und der Billing-SOAP-Partner werden hier als bereits im Cluster (oder extern) erreichbar vorausgesetzt - beide bleiben laut Migrationsplan technologisch unveraendert, ihre Bereitstellung ist nicht Teil dieser Migration.

Ehrliche Grenze: nicht gegen einen echten Cluster verifiziert

Anders als bei Oracle/IBM MQ im Legacy-Reactor (dort per Testcontainers real gegen echte Container verifiziert), sind diese OpenShift-Manifeste nicht gegen einen echten Cluster angewendet worden. Auf der Entwicklungsmaschine sind oc-CLI (OKD 4.21) und CRC (OpenShift Local) zwar installiert, aber:

Ein crc start ist schwergewichtig (VM-Provisionierung, mehrere GB Download, typischerweise 20-30+ Minuten, hoher RAM-Bedarf) und in dieser Sandbox-Umgebung zusaetzlich durch dieselbe Netzwerk-Unzuverlaessigkeit gefaehrdet, die bereits den docker build-Versuch fuer novaris-policy-core-modern/Dockerfile mehrfach scheitern liess (siehe dessen README).
Die YAML-Dateien wurden stattdessen mit python -c "yaml.safe_load_all(...)" auf reine Syntaxkorrektheit geprueft (alle neun Dateien geparst ohne Fehler) - das beweist wohlgeformtes YAML, aber nicht Anwendbarkeit gegen echte Strimzi-/OpenShift-CRDs.
Die eingebauten Kubernetes-Ressourcentypen (Deployment, Service, Namespace) folgen Standard-Schemas und Best-Practice-Mustern (Ressourcen-Requests/Limits, Liveness-/Readiness- Trennung, Labels); die OpenShift-spezifische Route und die Strimzi-Custom-Resources sind nach offizieller Dokumentation aufgebaut, aber ebenfalls nicht live getestet.

Diese Grenze wird hier bewusst genauso offen dokumentiert wie das Testcontainers-Docker-Engine- API-Problem und das Liberty-EAR-Deployment-Detail im Legacy-Reactor - eine echte Cluster-Verifikation ist ein sinnvoller naechster Schritt, aber ausserhalb des mit vertretbarem Aufwand in dieser Umgebung Erreichbaren.

⌂ Cockpit