Letzter Schritt der Migration, wie von Anfang an vom Nutzer verlangt ("zuletzt ...
migrieren"). Ersetzt WebSphere-Liberty-EAR-Deployment und Liberty-server.xml durch
Container-Images und OpenShift-Manifeste.
novaris-modern-parent/openshift/ - acht Kubernetes-/OpenShift-/Strimzi-Manifeste
(Namespace, Kafka-Cluster + drei Topics, ConfigMap, Secret-Template, drei
Deployment/Service/Route-Definitionen). Siehe novaris-modern-parent/openshift/README.md
fuer die vollstaendige Datei-fuer-Datei-Erklaerung.Dockerfile je Spring-Boot-Modul sowie fuer die React-SPA (novaris-policy-core-modern,
novaris-claims-modern, novaris-notification-modern, novaris-policy-web-modern-spa) -
mehrstufiger Build (Maven-/Node-Build-Stage +
Spring-Boot-Layertools-Extraktion), non-root User.novaris-modern-parent/Jenkinsfile - vierstufige Pipeline (local/test/qs/prod), baut auch
Lint/Build und Container fuer die SPA, strukturell
identisch zum Legacy-Jenkinsfile, aber mit Container-Image-Build statt EAR-Package und
ci/scripts/deploy-openshift.sh statt ci/scripts/deploy.sh.Die beiden Reactors haben grundlegend unterschiedliche Deployment-Artefakte (EAR vs. Container-Image) und Zielplattformen (WebSphere Liberty vs. OpenShift) - ein gemeinsames Jenkinsfile haette entweder mit verschachtelten Bedingungen beide Welten vermischt oder waere faktisch zwei Pipelines in einer Datei gewesen. Zwei eigenstaendige, parallele Jenkinsfiles (je Reactor eines) sind die klarere Trennung und spiegeln den Strangler-Fig-Ansatz des ganzen Projekts wider: Legacy und Modern sind unabhaengige Auslieferungswege.
Wie in 03-messaging-jms-zu-kafka.md begruendet, war der Wechsel zu Kafka von Anfang an an
den OpenShift-Schritt gekoppelt: openshift/kafka-cluster.yaml bringt AMQ Streams (Strimzi)
als den nativen Kafka-Betrieb auf OpenShift - der eigentliche IBM-MQ-Ersatz auf
Infrastruktur-Ebene, nicht nur auf Code-Ebene (M3 hatte bereits den Anwendungscode auf Kafka
umgestellt, aber gegen einen lokalen/externen Broker; M5 liefert jetzt den Broker selbst als
Teil der Zielplattform).
Wie in novaris-policy-core-modern/README.md und openshift/README.md ausfuehrlich
dokumentiert: weder der docker build (mehrfach an Container-internem Netzwerkzugriff zu
Maven Central/Docker Hub gescheitert, Connect timed out/DNS-Fehler trotz durchgehend
funktionierendem Host-Internetzugriff) noch eine echte OpenShift-Cluster-Anwendung der
Manifeste wurden in dieser Entwicklungsumgebung erfolgreich durchgefuehrt. Beides folgt
demselben Muster wie das bereits im Legacy-Reactor dokumentierte
Testcontainers-Docker-Engine-API-Problem: die Docker-Umgebung dieser Sandbox ist fuer
Container-interne Netzwerkzugriffe unzuverlaessig, waehrend Host-seitige Werkzeuge (Maven,
Kafka embedded broker, echte SOAP-Endpoints per Endpoint.publish) durchgehend funktionierten
und entsprechend real (nicht simuliert) verifiziert werden konnten - siehe die Test- und
End-to-End-Nachweise in M1-M4.
Was stattdessen real verifiziert wurde:
- Alle YAML-Manifeste sind syntaktisch gueltig (python -c "yaml.safe_load_all(...)", alle
acht Dateien).
- ci/scripts/deploy-openshift.sh laeuft korrekt durch alle Fehlerpfade (fehlende Stage,
fehlende Credentials) und den Erfolgspfad (Syntaxpruefung + simulierte Ausgabe).
- Der Jenkinsfile-Aufbau folgt exakt dem bereits im Legacy-Reactor etablierten, strukturell
bewaehrten Muster (vier Stages, Freigabe-Gates, withCredentials).
"neue branch erstellen dann migration plan erstellen ... und zuletzt refactorieren und auf
openshift migrieren" - Branch (M0), Migrationsplan (M0-Doku), Refactoring (M1-M4, mit
docs/70-migration/06-refactoring-taxonomie.md als expliziter Kennzeichnung im Code) und
OpenShift-Migration (M5, mit ehrlich dokumentierten Werkzeug-/Umgebungsgrenzen) sind
durchlaufen.