Spring Boot und PostgreSQL auf SKE und PostgreSQL Flex umstellen

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

Seitlich wischen, um die ganze Tabelle zu sehen

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:

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:

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.

Seitlich wischen, um die ganze Tabelle zu sehen

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:

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

Seitlich wischen, um die ganze Tabelle zu sehen

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

Code & Registry github.com Ausführbarer Migrations- und Recovery-Workflow Das Referenzrepository liefert genaue Befehlsvoraussetzungen, Nachweisformate, Schutzmechanismen und Validierungsumfang. Repository öffnen