--- title: "Spring Boot und PostgreSQL auf SKE und PostgreSQL Flex umstellen" description: "Spring-Boot-Replatform kontrolliert umsetzen: mit Quellnachweisen, isolierter PostgreSQL-Probe, freigegebenem Cutover, geprüftem Rollback und Betriebsübergabe." scfAsset: managed: false category: "runbook" external: false tags: ["design-and-mobilize", "use-cases", "replatform", "spring-boot", "postgresql", "ske", "cutover", "migration"] maintainers: - user: "lukas.weberruss" role: true website: true source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/runbook-replatform-spring-boot/" source_file: "docs/de/migration/assetcontainer/stackit/runbook-replatform-spring-boot.mdx" --- ## Anwendungsfall Überführen Sie die Spring-Music-Anwendung von einer VM zu STACKIT Kubernetes Engine und ihre Daten von selbstverwaltetem PostgreSQL zu PostgreSQL Flex. Behalten Sie Anwendungs-JAR und fachliches Verhalten bei und führen Sie Kubernetes-Deployment, Gateway API, DNS und Managed Observability ein. Dieses Runbook beschreibt die Freigaben und die betriebliche Reihenfolge rund um die Befehle von `scripts/migrate_postgres.py` im Referenzrepository. Infrastrukturbereitstellung und Datenbankaustausch sind getrennte Vorgänge. Ein erfolgreiches Terraform-Apply ist keine Migrationsabnahme. ## Umfang und Annahmen Die Referenz migriert das Schema `public` und validiert `public.album` anhand von Zeilenanzahl und deterministischem Fingerprint. Die getestete Eingabe ist das Rehost-Beispiel mit acht Alben, kein Export einer Live-Quelle. Ein realer Workload benötigt einen eigenen kompatiblen Export, eine Schemabewertung, fachliche Tests und Recovery-Ziele. Geben Sie Ausfallzeit frei: Dies ist eine Migration mit Schreibstopp und Dump/Restore, keine Replikation oder unterbrechungsfreie Umschaltung. Das Ziel verwendet eine eigene Anwendungs- und Probedatenbank, Datenbankverbindungen mit TLS-Pflicht und einen temporären clusterinternen Migrationsclient. Das Skript stoppt weder Quellschreiber noch schaltet es Client-Traffic um, konfiguriert öffentliches TLS oder automatisiert den Failback zur Quelle. Diese Aufgaben liegen beim Betreiber. ## Rollen und Verantwortlichkeiten | Rolle | Verantwortete Entscheidung oder Nachweis | | --- | --- | | Migrationsleitung | Zeitfenster, Kontrollpunkte, Go/No-Go-Befugnis, Rollback-Deadline und Incident-Koordination | | Anwendungsverantwortliche | Vollständige Erfassung der Schreiber, Quellschreibstopp, fachliche Abnahme und Abgleich von Schreibzugriffen nach dem Cutover | | Plattform-Engineering | Freigegebener Terraform-Plan, SKE-Zugriff, Gateway- und DNS-Bereitschaft, pausierte Reconciliation | | Datenbankverantwortliche | Konsistente Quellnachweise, Probe, geschütztes Backup, Restore-Integrität und Rollback-Ausführung | | Betriebsverantwortliche | Telemetrie, Incident-Zuweisung, Recovery-Verantwortung, Aufbewahrung und Ende der Stabilisierung | ## Entscheidungs- und Freigabepunkte der Migration - **Bereit zur Migration**: Zieldesign, Zugriffsgrenzen, Ausfallzeit, Verantwortlichkeiten und messbare Abnahmekriterien vor Beginn des Fensters freigeben. - **Bereit zum Cutover**: Quellschreibzugriffe einfrieren und einen konsistenten finalen Dump mit passenden, aktuellen Probenachweisen verlangen. Infrastruktur-Bereitschaft allein erlaubt keinen Datenaustausch. - **Geschützte Ausführung**: Konkurrierende Schreiber und Reconciliation ausschließen, das Zielbackup vor dem Cutover nachweisen und den transaktionalen Restore vor dem Workload-Neustart validieren. - **Abnehmen oder wiederherstellen**: Übereinstimmende Daten, erfolgreiche fachliche Abläufe, funktionierenden Client-Traffic und tatsächliche Telemetrie verlangen. Rollback vor der Deadline entscheiden; Quell-Failback und Abgleich späterer Schreibzugriffe bleiben separate Entscheidungen. - **Bereit für den Betrieb**: Nachweise und Recovery-Verantwortung übergeben, den Workload stabilisieren und Automatisierung bewusst wieder aufnehmen. Kapazitäts- und HPA-Experimente gehören in ein späteres Änderungsfenster. Diese Freigabepunkte erläutern das Kontrollmodell. Die folgenden Abschnitte liefern das ausführbare Verfahren und die Nachweisanforderungen für den technischen Walkthrough. ## Prüfungen vor der Migration Bestätigen Sie Schreibkontrolle, pausierte Reconciliation, Verantwortlichkeiten, Abnahmekriterien und Rollback-Deadline. - **Quellbaseline**: JAR-Prüfsumme, Java- und PostgreSQL-Versionen, Schemaabhängigkeiten, Datenmenge und Änderungsrate, geplante Jobs, Integrationen und Recovery-Ziele erfassen. - **Quellnachweise**: Vertrauenswürdigen Dump und Manifest aus einem konsistenten Snapshot validieren; Prüfsumme, erwartete Zeilenanzahl und Fingerprint dokumentieren. Den finalen Dump nach dem Schreibstopp proben. - **Zielbereitschaft**: Geprüftes Infrastruktur-Apply abschließen; SKE-Kapazität, Artefaktzugriff, Flex-Konnektivität und ACLs, Gateway-Zustände, DNS, Anwendungsantworten und beide Metrik-Jobs prüfen. - **Zugriff und Sicherheit**: Kubeconfig und Berechtigungen prüfen, State und Pläne schützen, Secrets und Nachweise einschränken sowie HTTP- und öffentliche Metrikgrenzen passend zur Datenklassifikation auflösen. - **Schreibkontrolle**: HPA und Lastgenerierung deaktivieren, weitere Zielschreiber stoppen sowie Terraform, GitOps und geplante Deployment-Jobs während der Migration pausieren. Das Ziel für genau einen Betreiberworkflow reservieren. - **Recovery-Bereitschaft**: Zielidentität, Nachweisort, geschützten Backup-Speicher außerhalb des Containers, Rollback-Befugnis, Deadline, Traffic-Umschaltung und Quellaufbewahrung vereinbaren. - **Abnahme**: Erlaubte Ausfallzeit, Dateninvarianten, fachliche Tests, Fehler- und Latenzgrenzen sowie Reaktion auf fehlende Telemetrie vor Beginn des Fensters festlegen. ## Ablaufplan für das Cutover-Fenster ### Phase 1: Quelle und Ziel vorbereiten 1. Freigegebenen Codestand, Variablendatei, Projekt, Cluster, Namespace und Zieldatenbank bestätigen. 2. Das Ziel über einen geprüften gespeicherten Terraform-Plan bereitstellen; fachfremden Ressourcenaustausch ablehnen. 3. `bash scripts/validate_gateway.sh` ausführen und Workload-Rollout sowie PostgreSQL-Konnektivität prüfen. 4. Quellnachweise und Ausgangsverhalten des Ziels erfassen. Ein Ziel mit Initialdaten ist kein abgenommenes migriertes Ziel. 5. `enable_springboot_hpa = false`, `enable_load_generator = false` und `deploy_postgres_migration_job = false` setzen; diese Einstellungen vor dem Pausieren der Infrastrukturautomatisierung anwenden. ### Phase 2: Schreibzugriffe einfrieren und proben 1. Go/No-Go-Freigabe einholen und alle Quellschreiber einschließlich Integrationen und Hintergrundjobs einfrieren. 2. Finalen konsistenten Dump und Manifest über das freigegebene Quellverfahren exportieren. 3. Die Probe im Replatform-Repository mit dem freigegebenen Artefaktverzeichnis ausführen: ```bash python3 scripts/migrate_postgres.py rehearse \ --artifacts ../stackit-cmf-Rehost-springboot/artifacts \ --evidence .tmp/migration-run ``` 4. Übereinstimmende Prüfsumme, Zeilenanzahl, Fingerprint und Zielidentität verlangen; die unveränderte Anwendungsdatenbank bestätigen. 5. Bestätigen, dass die erfolgreiche Probe jünger als 24 Stunden und der finale Dump unverändert ist. Veraltete oder unpassende Nachweise ablehnen. ### Phase 3: Cutover und Freigabe 1. Quellschreibstopp, Ausschluss weiterer Zielschreiber, pausierte Reconciliation, Entscheidungsfrist und verfügbaren Nachweisspeicher erneut bestätigen. 2. Den explizit bestätigten Cutover ausführen: ```bash python3 scripts/migrate_postgres.py cutover \ --artifacts ../stackit-cmf-Rehost-springboot/artifacts \ --evidence .tmp/migration-run \ --source-write-frozen --confirm-target springmusic ``` 3. Verlangen, dass das Skript die Anwendungsreplikas stoppt, den Zieldump vor dem Cutover sichert und dessen Restore in der Probedatenbank vor dem Quellimport nachweist. 4. Erfolgreichen transaktionalen Quellrestore und Datenprüfungen verlangen, bevor das Skript die ursprüngliche Replikazahl wiederherstellt. Eine nach einem Fehler gestoppte Anwendung untersuchen; nicht mit Terraform übersteuern. 5. Technische und fachliche Validierung abschließen und anschließend den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten. Den neuen Clientpfad und den fortbestehenden Quellschreibstopp prüfen. 6. Abnahme und Schreibverantwortung dokumentieren. Nach Skriptende und korrekter Replikazahl einen Terraform-Plan auf Drift prüfen und eine reine Kubeconfig-Aktualisierung in Outputs erklären; während der Abnahme keine fachfremden Änderungen anwenden. ## Validierungscheckliste Nehmen Sie nur mit übereinstimmenden Datennachweisen, erfolgreichen Clientanfragen, gesunder Laufzeit und tatsächlicher Telemetrie ab. | Freigabepunkt | Erforderlicher Nachweis | | --- | --- | | Datenintegrität | Prüfsumme des Quellmanifests, erwartete Anzahl und Fingerprint stimmen mit dem wiederhergestellten Ziel überein; das Migrationsjournal benennt das richtige Projekt und die Datenbank | | Laufzeit | Ursprüngliche Replikazahl wiederhergestellt, gesunder Rollout, keine unerklärten Neustarts oder Verbindungsfehler | | Netzwerkverkehr | Gateway akzeptiert, HTTPRoute-Referenzen aufgelöst, DNS entspricht dem Gateway, tatsächliche Clientanfragen erreichen das beabsichtigte Ziel | | Fachliches Verhalten | Migrierte Alben sichtbar und freigegebene Benutzerabläufe erfolgreich; Schreibtests besitzen einen vereinbarten Bereinigungs- und Abgleichplan | | Datenbanktransport | Anwendung und Migration verlangen TLS; ACL erlaubt nur freigegebenes SKE-Egress oder explizit genehmigte Ausnahmen | | Observability | Beide Scrape-Jobs liefern tatsächliche `up=1`-Messwerte, der Exporter meldet Datenbankzustand und Dashboard-Werte entsprechen dem Workload | | Recovery | Backup vor dem Cutover, Prüfsumme, ursprünglicher Fingerprint und Journal privat aufbewahrt und in geschützten dauerhaften Speicher kopiert | | Konfiguration | Geprüfter Plan nach der Migration ohne unerklärte Ressourcendrift; Betriebszustände von Quelle und Ziel dokumentiert | Ein erfolgreicher öffentlicher HTTP-Aufruf erfüllt allein keine produktive HTTPS-Anforderung. Das Beispiel-Dashboard ersetzt keine unabhängige fachliche, Latenzperzentil-, Fehlerraten- oder Recovery-Validierung. ## Rollback-Kriterien und Schritte Stellen Sie bei einem freigegebenen Auslöser das geschützte Ziel wieder her; gleichen Sie Schreibzugriffe nach dem Cutover ab und entscheiden Sie den Quell-Failback separat. ### Rollback-Auslöser Treffen Sie die vereinbarte Entscheidung vor der Deadline, wenn Dateninvarianten verletzt sind, ein kritischer fachlicher Ablauf nicht im Fehlerbehebungsfenster wiederhergestellt werden kann, Zielinstabilität die Abnahmegrenzen überschreitet oder keine vertrauenswürdige Telemetrie festgestellt werden kann. Bewahren Sie Migrationsjournal und Logs auf. ### Rollback der Zieldatenbank 1. Clientschreibzugriffe stoppen oder isolieren und automatische Reconciliation pausiert lassen. Rollback-Befugnis und Zielidentität bestätigen. 2. Das geschützte Ziel vor dem Cutover mit dem ursprünglichen Nachweisverzeichnis wiederherstellen: ```bash python3 scripts/migrate_postgres.py rollback \ --evidence .tmp/migration-run --confirm-target springmusic ``` 3. Validierung der Backup-Prüfsumme, einen separaten Dump des aktuellen Ziels vor dem Rollback und Übereinstimmung des ursprünglichen Datenfingerprints vor dem Neustart verlangen. 4. Gateway-Erreichbarkeit, Anwendungsverhalten und wiederhergestellten Zielzustand prüfen. Nicht annehmen, dass dieser Zustand die neuesten Quelldaten enthält. 5. Alle Schreibzugriffe nach dem Cutover im Dump vor dem Rollback für einen expliziten Abgleich bewahren. Sie werden nicht automatisch in die wiederhergestellten Daten übernommen. ### Quell-Failback und unterbrochene Läufe Die Rückkehr der Benutzer zur VM ist eine separate Entscheidung: Quellintegrität bestätigen, angenommene Zielschreibzugriffe abgleichen, Client-Traffic nach dem freigegebenen Verfahren umleiten und genau einer Seite Schreibzugriffe erlauben. Der Restore des Ziels vor dem Cutover allein führt diese Schritte nicht aus. Schlägt der Cutover fehl, bevor ein gültiges Backup dokumentiert ist, prüfen Sie Journal und Datenbank gemeinsam mit den Datenbankverantwortlichen. Überschreiben Sie niemals das Nachweisverzeichnis und starten Sie den Cutover nicht blind erneut. Prüfen Sie nach einem beendeten Prozess verbliebene Pods mit Präfix `springmusic-migration-*` und das gestoppte Deployment, bevor Sie fortfahren. Die lokale Migrationssperre koordiniert keine unterschiedlichen Ausführungshosts. ## Übergabe an den Betrieb Übergeben Sie Konfiguration, Abnahmenachweise, Dashboards, Incident-Verantwortung und Entscheidungen zur Quellaufbewahrung. Übergeben Sie den geprüften Konfigurationsstand, Workload- und Gateway-Inventar, Quellmanifest, Migrationsjournal, Backup-Orte, Abnahmeergebnisse, Dashboard-URL und Rollback-Entscheidung. Halten Sie Zugangsdaten aus dem Übergabedokument heraus und verweisen Sie auf den freigegebenen Secret-Speicher. Vereinbaren Sie ein zum Workload passendes anfängliches Stabilisierungsfenster von 24 bis 72 Stunden. Benennen Sie Incident- und Datenbank-Recovery-Verantwortliche, bestätigen Sie Aufbewahrungs- und Restore-Verfahren und testen Sie Alarmzustellung, bevor Sie sich darauf verlassen. Flex-Backups ergänzen Migrationsdumps; ein verifizierter Dump-Rollback ist kein Nachweis für Managed-Service-Recovery. Beenden Sie die Stabilisierung nur bei dauerhaft gesundem fachlichem Verhalten, vollständiger Telemetrie, ohne ungelöste kritische Probleme und mit Betriebsfreigabe. Nehmen Sie pausierte Automatisierung bewusst wieder auf. Bewahren Sie Quelldaten und geschützte Nachweise auf, bis die vereinbarten Aufbewahrungs- und Abgleichkriterien die Stilllegung erlauben. Beginnen Sie HPA- und Kapazitätsexperimente erst nach der Stabilisierung in einem separaten Änderungsfenster. ## Vorlage für das Nachweisprotokoll | Kontrollpunkt | Verantwortliche Rolle | Zeitstempel | Ergebnis | Nachweisreferenz | | --- | --- | --- | --- | --- | | Ziel und Clientpfad bereit | Plattform-Engineering | JJJJ-MM-TT HH:MM | Bestanden/Fehlgeschlagen | Geschützter Eintrag | | Quellschreibstopp und finaler Export | Anwendungs- und Datenbankverantwortliche | JJJJ-MM-TT HH:MM | Bestanden/Fehlgeschlagen | Manifest und Freigabe | | Finale Probe abgenommen | Datenbankverantwortliche | JJJJ-MM-TT HH:MM | Bestanden/Fehlgeschlagen | Probejournal | | Backup vor dem Cutover nachgewiesen | Datenbankverantwortliche | JJJJ-MM-TT HH:MM | Bestanden/Fehlgeschlagen | Backup-Prüfsumme und Restore-Ergebnis | | Cutover und Integrität abgenommen | Datenbankverantwortliche | JJJJ-MM-TT HH:MM | Bestanden/Fehlgeschlagen | Migrationsjournal | | Fachlichkeit und Netzwerkverkehr abgenommen | Anwendungsverantwortliche | JJJJ-MM-TT HH:MM | Bestanden/Fehlgeschlagen | Test- und Routing-Nachweise | | Drift und Telemetrie geprüft | Plattform-Engineering | JJJJ-MM-TT HH:MM | Bestanden/Fehlgeschlagen | Plan- und Metriknachweise | | Übergabe oder Rollback abgeschlossen | Migrationsleitung | JJJJ-MM-TT HH:MM | Bestanden/Fehlgeschlagen | Unterzeichnete Entscheidung |