Rehost Spring Boot Service auf VM

Use Case

• Migrationsstrategie: Rehost (Lift-and-Shift)
• Anwendungstyp: Spring-Boot-Service (JAR), kein Kubernetes-Ziel
• Zielplattform: VM-basierter Runtime-Betrieb auf STACKIT
• Daten-Backend: PostgreSQL

Scope und Annahmen

• In Scope: Terraform-Provisioning, Ansible-Konfiguration, Quelldump-Nachweise, Probe in einer temporären Datenbank, kontrollierter Restore, Laufzeitvalidierung, Rollback, Observability und Server-Backup-Zeitplan.
• Out of Scope: Code-Refactoring, Wechsel der Datenbank-Engine, Load Balancing, DNS-Switch, TLS-Terminierung, Multi-VM-Verfügbarkeit, Kubernetes, Cloud Foundry und PostgreSQL Flex.
• Annahmen: Die Quelle verwendet eine PostgreSQL-Version, die mit den Restore-Werkzeugen im Ziel kompatibel ist; freigegebene Quell-CIDRs für SSH und Applikationszugriff sind bekannt.

Rollen und Ownership

• Migrationsleitung: Steuert Zeitplan, Checkpoints und Go/No-Go-Entscheidung.
• Application Owner: Validiert das Verhalten der Anwendung und business-kritische User Journeys.
• Platform Engineer: Bereitet VM, eingeschränkte Netzwerkregeln, Monitoring und Backup-Zeitplan vor.
• DB Owner: Führt DB-Backup, Restore, Konsistenzprüfungen und Rollback-Trigger aus.
• Operations Owner: Übernimmt den Handover und verantwortet Day-1/Day-2 Incident Response.

Pre-Migration-Checks

• Access Readiness: SSH, Deployment-Credentials, DB-Zugriff und Secrets-Zugriff sind validiert.
• Baseline erfasst: Aktuelle Versionen, Umgebungsvariablen, Ports, Zertifikate und geplante Jobs sind dokumentiert.
• Kapazität validiert: CPU, RAM, Disk-IOPS und Storage auf der Ziel-VM sind bestätigt.
• Security-Controls bereit: Firewall-Regeln, IAM-Mapping, TLS-Chain und Logging sind aktiv.
• Quelldaten bereit: Dump-Prüfsumme, erwartete Datensatzanzahl und deterministischer Daten-Fingerprint sind erfasst.
• Rollback-Readiness: Dump von vor dem Restore, erwartete ursprüngliche Datensatzanzahl, Entscheidungsbefugnis und Deadline sind abgestimmt.

Run-Plan (Cutover-Fenster)

Phase 1: Ziel-Runtime vorbereiten

1. Ziel-App-User und benötigte Filesystem-Struktur anlegen.
2. Java-Runtime und unterstützende OS-Pakete installieren.
3. App-Artefakt in das Ziel-Verzeichnis deployen.
4. Service-Unit (systemd) und Environment-Datei konfigurieren.
5. Selbstverwaltetes PostgreSQL installieren, Application Role und Datenbank erstellen und den Zugriff auf localhost beschränken.
6. Node Exporter, Observability Scraping und Server-Backup-Zeitplan aktivieren.

Phase 2: Daten- und Konfigurationsabgleich

1. PostgreSQL-Dump im Custom Format ohne Ownership und Privileges der Quelle erstellen.
2. Prüfsumme, erwartete Datensatzanzahl und deterministischen Fingerprint erfassen und validieren.
3. ./scripts/run_migration_rehearsal.sh gegen eine temporäre Zieldatenbank ausführen.
4. Bestätigen, dass die Probe ihre temporäre Datenbank entfernt und die produktive Zieldatenbank nicht verändert hat.
5. Den ursprünglichen Ziel-Rollback-Dump in einer separaten temporären Datenbank prüfen.

Phase 3: Cutover und Release

1. Schreibzugriffe auf der Quelle einfrieren und den finalen freigegebenen Dump erstellen.
2. ./scripts/run_cutover.sh --confirm mit den freigegebenen Quelldaten ausführen.
3. Verlangen, dass der gespeicherte Terraform-Plan ausschließlich die Ansible-Orchestrierungsressource ändert.
4. Datensatzanzahl, Fingerprint, Ownership, Schreibverhalten der Application Role, Services und Endpunkt validieren.
5. Abschließenden Terraform-No-op-Plan verlangen, Abnahme dokumentieren und Stabilisierungsbeobachtung starten.

Validierungscheckliste

• Technische Gesundheit: Spring Boot, PostgreSQL und Node Exporter sind aktiv; lokale und freigegebene öffentliche HTTP-Checks sind erfolgreich.
• Funktionale Checks: Die Anwendung liefert die migrierten Spring-Music-Datensätze.
• Datenprüfungen: Erwartete Datensatzanzahl und Fingerprint stimmen; Tabellen gehören der Application Role.
• Security-Checks: Runtime Environment und Rollback-Dump sind nur für root beziehungsweise den Datenbank-Owner lesbar.
• Operations-Checks: Observability Scrape, Server-Backup-Zeitplan, Nachweisdateien und Eskalations-Ownership sind geprüft.

Rollback-Kriterien und Schritte

Rollback-Trigger

• Kritischer funktionaler Fehler: Kern-Business-Flow ist nach Fix-Fenster nicht verfügbar.
• Datenintegritätsrisiko: Abweichung in kritischen Datensätzen ohne schnelle Remediation.
• Betriebliche Instabilität: Wiederholte Restarts oder nicht aufgelöste kritische Alerts.

Rollback-Schritte

1. Freigegebene Rollback-Entscheidung vor der Deadline auslösen und Logs sowie Nachweise sichern.
2. ./scripts/rollback_postgresql.sh --confirm ausführen, um Spring Boot zu stoppen und die aktuelle Zieldatenbank zu bewahren.
3. Geschützten Dump von vor dem Cutover wiederherstellen und die erwartete ursprüngliche Datensatzanzahl validieren.
4. Spring Boot neu starten und lokale sowie freigegebene öffentliche Erreichbarkeit validieren.
5. Vereinbarten Betriebszustand von Quelle oder Ziel wieder aufnehmen und Rollback-Nachweis sowie Entscheidung veröffentlichen.

Handover an Operations

• Übergabe-Artefakte: Finales Konfigurationspaket, Deployment-Manifest, Validierungsnachweise, Rollback-Log.
• Ownership-Transfer: Benannter On-Call-Owner und Eskalationsweg sind bestätigt.
• Stabilisierungsphase: 24-72 Stunden mit erhöhtem Monitoring und täglicher Statusprüfung.
• Exit-Kriterien: Keine kritischen Alerts, stabile zentrale Metriken und Business-Owner-Sign-off.

Nachweisprotokoll-Vorlage

Seitlich wischen, um die ganze Tabelle zu sehen

Checkpoint	Owner	Timestamp	Ergebnis	Evidence Link
Ziel-VM-Runtime vorbereitet	Platform Engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Probe abgeschlossen	DB Owner	YYYY-MM-DD HH:MM	Pass/Fail	link
DB-Restore und Integritätscheck	DB Owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Terraform-No-op bestätigt	Platform Engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Post-Cutover Business-Checks	Application Owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Handover akzeptiert	Operations Owner	YYYY-MM-DD HH:MM	Pass/Fail	link