Rehost to STACKIT: Spring Boot mit Terraform und Ansible

Migration migrate optimize rehost observability +2

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

STACKIT

Migration design-and-mobilize design runnable-example rehost +3

Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC.

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

Migration

Runbook

Rehost Spring Boot Service auf VM

STACKIT

Migration design-and-mobilize design target-architecture rehost +4

Ausführbares Migrations-Runbook für den Rehost eines Spring-Boot-JARs und PostgreSQL auf eine STACKIT VM mit Probe, nachweisbasiertem Cutover, Validierung und Rollback.

Rehost Spring Boot Service auf VM

Migration

Runbook

Blueprint

Spring Boot hybrid access with VPN and central firewall

STACKIT

Open Source

Referenzarchitektur für Spring Boot auf STACKIT mit hybrider Anbindung über VPN und zentraler Firewall-Inspektion im Hub-and-Spoke-Modell für Migration.

Spring Boot hybrid access with VPN and central firewall

Migration

Blueprint

Migration design-and-mobilize design runnable-example rehost +4

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Migration design-and-mobilize design target-architecture rehost +5

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Spring Boot mit Terraform und Ansible rehosten

Migration

Runbook

Blueprint

Spring Boot und PostgreSQL auf einer VM mit Observability und Backup

STACKIT

Validierte Rehost-Architektur für ein Spring-Boot-JAR und selbstverwaltetes PostgreSQL auf einer STACKIT VM mit eingeschränktem Ingress, Observability und Server Backup.

Spring Boot und PostgreSQL auf einer VM mit Observability und Backup

Migration

Blueprint

Migration design-and-mobilize use-cases app-stack rehost +1

VM-Anwendungsmigration mit kontrolliertem Cutover

STACKIT

Open Source

Runbook-Vorlage für die Migration einer Anwendung mit VM-Runtime auf STACKIT mit klaren Voraussetzungen, Cutover-Governance und definierten Rollback-Grenzen.

VM-Anwendungsmigration mit kontrolliertem Cutover

Migration

Runbook

Anleitung

MI1: Rehost- und Replatform-Guide

STACKIT

Migration design-and-mobilize design rehost replatform +2

Managed Asset Marketplace

Technische Anleitung für Rehost und Replatform bestehender On-Premise-Workloads nach STACKIT mit Tooling, Reihenfolge und Validierung für planbaren Cutover.

MI1: Rehost- und Replatform-Guide

Migration

Anleitung

Das Runbook-Asset beschreibt die PostgreSQL-Flags und den optionalen Dump-basierten Restore-Pfad.

Install

Manuelle Installations-Schritte für Ausnahme-Workloads beschreiben.

Ziel-VM manuell erstellen und vorbereiten: VM über Portal oder CLI bereitstellen, erforderlichen Storage anbinden und OS-Hardening sowie Patch-Baseline anwenden.
Runtime und Abhängigkeiten manuell installieren: Benötigte Runtime-Pakete, System-Bibliotheken und Service-User/-Gruppen gemäß Anleitung zur Installation des Produkts einrichten.
Anwendung klassisch installieren: Geführte Installationsschritte (zum Beispiel Installer- oder Setup-Wizard-Ablauf) ausführen, um das Quell-Deployment-Modell auf der Ziel-VM nachzubilden.
Status der Installation validieren: Service-Start, Rechte auf Dateien, erforderliche Ports, DNS-Erreichbarkeit und ausgehende Konnektivität prüfen.
Cloud-Design-Patterns
Runbook Blueprint

Config

Manuelle Konfiguration der Laufzeit und Controls festlegen.

Konfiguration der Quelle für den Kontext im Ziel spiegeln: Einstellungen der Anwendung aus der Umgebung der Quelle nachbilden und auf Ziel-Endpoints, DNS, Zertifikate und Service-Integrationen anpassen.
Security- und Einstellungen für Zugriffe anwenden: Service-Credentials, Secret-Handling und Least-Privilege-Zugriffe für den Betrieb im Ziel konfigurieren.
Standards für den Betrieb ausrichten: Logging-Ziele, Metrics-Exporter, Backup-Zeitpläne und Retention-Baselines festlegen.
Konfigurationsparität validieren: Smoke-Checks ausführen, damit die Zielinstanz funktional dem Quellbaseline-Verhalten entspricht.
Runbook Blueprint

Deploy

Manuelle Deployment-Sequenz und Release-Checks definieren.

Finales Zeitfenster für die Migration planen: Freeze-Fenster, Kommunikations-Checkpoints und Rollback-Autorität für den Wechsel in den Produktivbetrieb abstimmen.
Finale Datenmigration ausführen: Letzten Abgleich der Daten oder Restore-Schritte fahren und Konsistenzprüfungen vor Go-live bestätigen.
Live-Verkehr aktivieren: Kontrollierte Live-Schaltung auf die Zielumgebung durchführen und kritische Nutzer- sowie Integrationspfade prüfen.
Handover-Bereitschaft bestätigen: Nachweise dokumentieren, offene Risiken schließen und Ownership für Day-1-Betrieb übergeben.
Migrationsplan
Runbook Blueprint

OPS

Zielarchitektur

Blueprint

Spring Boot und PostgreSQL auf einer VM mit Observability und Backup

STACKIT

Migration design-and-mobilize design target-architecture rehost spring-boot vm postgresql observability backup

Validierte Rehost-Architektur für ein Spring-Boot-JAR und selbstverwaltetes PostgreSQL auf einer STACKIT VM mit eingeschränktem Ingress, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot repository Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Muster bildet das validierte Ziel mit geringer Änderungstiefe für das Spring-Boot-Rehost- Beispiel ab. Das JAR läuft weiterhin als systemd-Service, während PostgreSQL selbstverwaltet auf derselben VM verbleibt. Die Betriebsmodelle von Laufzeit und Datenbank bleiben damit VM-zentriert.

Die Baseline umfasst bewusst nur eine VM. Sie demonstriert wiederholbare Migrationskontrollen und Betriebsbereitschaft, nicht High Availability für Anwendung oder Datenbank.

Einsatz

Geringe Änderungstoleranz: Fachverhalten soll während der Migration stabil bleiben.
Kurze Zeitfenster für die Migration: Die Verlagerung der Laufzeit soll planbar und wiederholbar sein.
Betriebskontinuität: Teams behalten VM-zentrierte Betriebsabläufe auf STACKIT bei.

Architekturdiagramm

Designprinzipien

Ingress explizit einschränken: SSH- und Applikationsverkehr nur aus freigegebenen Quell-CIDRs zulassen; Exporter-Traffic ausschließlich aus STACKIT Service Ranges erlauben.
Credentials aus State und Inventar heraushalten: Das PostgreSQL-Passwort über die Prozessumgebung übergeben und die erzeugte Laufzeit-Environment-Datei nur für root lesbar speichern.
Observability-Minimum definieren: Infrastruktur- und Applikationssignale vor Go-live festlegen.
Recovery-Ebenen trennen: Den Datenbank-Dump von vor dem Restore für Cutover-Rollback und Server Backup für Disaster Recovery auf VM-Ebene verwenden.
Verfügbarkeitsgrenze benennen: Eine VM mit lokaler Datenbank bildet eine gemeinsame Failure Domain. Load Balancer oder zweiten Knoten nur mit separat entworfenem Datenbank- und Konsistenzmodell ergänzen.
Security Groups und Ingress-Regeln explizit halten: Nur erforderliche Ports und Protokolle freigeben.

Weiterführendes

Runbook Asset: Rehost Spring Boot with Terraform/OpenTofu and Ansible

Repository

Datei aus dem Beispiel kopieren: cp env.tfvars.example env.tfvars
Erforderliche Werte setzen:

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@sa.stackit.cloud"
parent_container_id         = "cmf-parent-container-id"
service_account_key_path    = "/path/to/stackit-sa-key.json"

run_ansible                 = true
jar_local_path              = "ansible/files/springboot-app.jar"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_observability        = true
enable_node_exporter        = true
enable_local_postgresql     = true
enable_server_backup        = true

Optionaler CMF-Flag-Wrapper (flags.env):

setup_project=true
setup_observability=true
setup_database=false
setup_workload=true
setup_loadgen=false
setup_dns=false

Ausführen:

terraform init
terraform apply -var-file=env.tfvars

Erwartetes Ergebnis: application_url stellt die Spring-Boot-Anwendung direkt von der VM auf dem konfigurierten Applikationsport bereit. PostgreSQL lauscht für die Anwendung auf localhost, Observability erfasst den Node Exporter und für das Boot Volume ist ein täglicher Backup-Zeitplan aktiv.

Verfügbarkeitsgrenze und Erweiterungen

Diese Baseline bietet kein automatisches Failover. Eine Load-Balancer- oder Multi-VM-Variante ist erst sinnvoll, nachdem Session Handling, PostgreSQL-Platzierung, Schreibkonsistenz, Health Checks, TLS und Traffic-Umschaltung gemeinsam entworfen und getestet wurden. Behandeln Sie dies als eigene Architekturentscheidung, nicht als implizite Eigenschaft dieses Rehost-Pfads.

LIVE

Referenzimplementierung

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

BASE

Arbeitsumgebung vorbereiten

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

SAFE

Private Zielparameter konfigurieren

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

SAFE

Quellnachweise vorbereiten

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

BASE

Ziel bereitstellen

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

STEP

Proben und freigeben

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

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

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

Phase 2: Daten- und Konfigurationsabgleich

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

Phase 3: Cutover und Release

Schreibzugriffe auf der Quelle einfrieren und den finalen freigegebenen Dump erstellen.
./scripts/run_cutover.sh --confirm mit den freigegebenen Quelldaten ausführen.
Verlangen, dass der gespeicherte Terraform-Plan ausschließlich die Ansible-Orchestrierungsressource ändert.
Datensatzanzahl, Fingerprint, Ownership, Schreibverhalten der Application Role, Services und Endpunkt validieren.
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

Freigegebene Rollback-Entscheidung vor der Deadline auslösen und Logs sowie Nachweise sichern.
./scripts/rollback_postgresql.sh --confirm ausführen, um Spring Boot zu stoppen und die aktuelle Zieldatenbank zu bewahren.
Geschützten Dump von vor dem Cutover wiederherstellen und die erwartete ursprüngliche Datensatzanzahl validieren.
Spring Boot neu starten und lokale sowie freigegebene öffentliche Erreichbarkeit validieren.
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

LIVE

Cutover

Migration design-and-mobilize design runnable-example rehost spring-boot migration vm

Rehost Spring Boot Service auf VM

STACKIT

Ausführbares Migrations-Runbook für den Rehost eines Spring-Boot-JARs und PostgreSQL auf eine STACKIT VM mit Probe, nachweisbasiertem Cutover, Validierung und Rollback.

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Kontrollierte Migrationswelle von Readiness über Cutover und Validierung bis zum Handover

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

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

Phase 2: Daten- und Konfigurationsabgleich

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

Phase 3: Cutover und Release

Schreibzugriffe auf der Quelle einfrieren und den finalen freigegebenen Dump erstellen.
./scripts/run_cutover.sh --confirm mit den freigegebenen Quelldaten ausführen.
Verlangen, dass der gespeicherte Terraform-Plan ausschließlich die Ansible-Orchestrierungsressource ändert.
Datensatzanzahl, Fingerprint, Ownership, Schreibverhalten der Application Role, Services und Endpunkt validieren.
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

Freigegebene Rollback-Entscheidung vor der Deadline auslösen und Logs sowie Nachweise sichern.
./scripts/rollback_postgresql.sh --confirm ausführen, um Spring Boot zu stoppen und die aktuelle Zieldatenbank zu bewahren.
Geschützten Dump von vor dem Cutover wiederherstellen und die erwartete ursprüngliche Datensatzanzahl validieren.
Spring Boot neu starten und lokale sowie freigegebene öffentliche Erreichbarkeit validieren.
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

LIVE

Freigegebenen Cutover ausführen

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

SAFE

Validieren oder zurückrollen

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

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

Phase 2: Daten- und Konfigurationsabgleich

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

Phase 3: Cutover und Release

Schreibzugriffe auf der Quelle einfrieren und den finalen freigegebenen Dump erstellen.
./scripts/run_cutover.sh --confirm mit den freigegebenen Quelldaten ausführen.
Verlangen, dass der gespeicherte Terraform-Plan ausschließlich die Ansible-Orchestrierungsressource ändert.
Datensatzanzahl, Fingerprint, Ownership, Schreibverhalten der Application Role, Services und Endpunkt validieren.
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

Freigegebene Rollback-Entscheidung vor der Deadline auslösen und Logs sowie Nachweise sichern.
./scripts/rollback_postgresql.sh --confirm ausführen, um Spring Boot zu stoppen und die aktuelle Zieldatenbank zu bewahren.
Geschützten Dump von vor dem Cutover wiederherstellen und die erwartete ursprüngliche Datensatzanzahl validieren.
Spring Boot neu starten und lokale sowie freigegebene öffentliche Erreichbarkeit validieren.
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

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

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

Phase 2: Daten- und Konfigurationsabgleich

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

Phase 3: Cutover und Release

Schreibzugriffe auf der Quelle einfrieren und den finalen freigegebenen Dump erstellen.
./scripts/run_cutover.sh --confirm mit den freigegebenen Quelldaten ausführen.
Verlangen, dass der gespeicherte Terraform-Plan ausschließlich die Ansible-Orchestrierungsressource ändert.
Datensatzanzahl, Fingerprint, Ownership, Schreibverhalten der Application Role, Services und Endpunkt validieren.
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

Freigegebene Rollback-Entscheidung vor der Deadline auslösen und Logs sowie Nachweise sichern.
./scripts/rollback_postgresql.sh --confirm ausführen, um Spring Boot zu stoppen und die aktuelle Zieldatenbank zu bewahren.
Geschützten Dump von vor dem Cutover wiederherstellen und die erwartete ursprüngliche Datensatzanzahl validieren.
Spring Boot neu starten und lokale sowie freigegebene öffentliche Erreichbarkeit validieren.
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

SAFE

Daten und Laufzeit verifizieren

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

SAFE

Apply und Abnahme nachweisen

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

GOAL

Stabilisierung

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

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

Phase 2: Daten- und Konfigurationsabgleich

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

Phase 3: Cutover und Release

Schreibzugriffe auf der Quelle einfrieren und den finalen freigegebenen Dump erstellen.
./scripts/run_cutover.sh --confirm mit den freigegebenen Quelldaten ausführen.
Verlangen, dass der gespeicherte Terraform-Plan ausschließlich die Ansible-Orchestrierungsressource ändert.
Datensatzanzahl, Fingerprint, Ownership, Schreibverhalten der Application Role, Services und Endpunkt validieren.
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

Freigegebene Rollback-Entscheidung vor der Deadline auslösen und Logs sowie Nachweise sichern.
./scripts/rollback_postgresql.sh --confirm ausführen, um Spring Boot zu stoppen und die aktuelle Zieldatenbank zu bewahren.
Geschützten Dump von vor dem Cutover wiederherstellen und die erwartete ursprüngliche Datensatzanzahl validieren.
Spring Boot neu starten und lokale sowie freigegebene öffentliche Erreichbarkeit validieren.
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

Referenzimplementierung

Das Migration Framework definiert Strategie, Design, Landing Zone, Migration und Betriebsprinzipien für Rehost-Workloads. Dieses Asset wendet diese Prinzipien auf eine konkrete, ausführbare Spring-Boot- und PostgreSQL-Implementierung auf STACKIT an.

Das gepflegte Repository ist die Source of Truth für Terraform, Ansible, Applikationsartefakte, Migrationsskripte, Validierung und Laufzeitkonfiguration. Dieses Asset beschreibt die Nutzung der Implementierung, ohne ihren vollständigen Quellcode zu duplizieren.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Öffnen Sie die ausführbare Terraform- und Ansible-Referenzimplementierung für den Rehost-Pfad von Spring Boot und PostgreSQL. Repository öffnen

Migrationskontext und Umfang

Dieses Beispiel bildet einen Application-Rehost-Pfad für einen Spring-Boot-Workload ab, konkret das Spring-Music-Beispiel. Der Fokus liegt auf der Verlagerung der Laufzeit nach STACKIT:

Infrastruktur-Rehost: Terraform stellt eine STACKIT VM, Boot Volume, Netzwerk, Public IP, Security Group, SSH-Key, Observability-Ressourcen und optional einen Server-Backup-Zeitplan bereit.
Application-Rehost: Ansible installiert Java, deployt das Spring-Boot-JAR und verwaltet es mit systemd, ohne das Laufzeitmodell der Anwendung zu ändern.
Stateful Rehost: Ansible installiert selbstverwaltetes PostgreSQL auf derselben VM. Der Datenbank-Layer wird in diesem Pfad nicht auf einen Managed Service umgestellt.
Kontrollierte Migration: Das Repository enthält getrennte Workflows für Probe, Cutover, Validierung und Rollback mit maschinenlesbaren Nachweisen.

Die validierte Baseline enthält bewusst keinen Application Load Balancer, DNS-Switch, mehrere VMs, Kubernetes, Cloud Foundry oder PostgreSQL Flex. Ergänzen Sie diese nur als separat entworfene und getestete Erweiterungen; sie sind nicht impliziter Bestandteil dieses Rehost-Beispiels.

Inhalt des Repositories

Provisioning: Terraform-Ressourcen für Netzwerk, Security, eine VM, Boot Volume, SSH-Key und Public IP.
Configuration Bridge: Terraform stößt Ansible nach dem Infrastruktur-Provisioning an.
Application Deployment: Ansible deployt ein konkretes Spring-Boot-Artefakt und konfiguriert einen systemd-Service.
VM-lokaler Datenbankpfad: PostgreSQL-Installation, Bootstrap von Application Role und Datenbank sowie Dump-basierter Restore mit Ownership- und Datenintegritätsprüfungen.
Operations-Baseline: STACKIT Observability erfasst Node-Exporter-Metriken; Terraform kann ein tägliches Server Backup für das Boot Volume der VM aktivieren.
Migrationskontrollen: Erzeugung des Quelldumps, unabhängige Restore-Validierung, Probe, Cutover, Rollback-Prüfung, Rollback-Ausführung und Nachweiserfassung.
Bereitstellbares Sample-Artefakt: Das Repository enthält ein ausführbares JAR, das die Standardkonfiguration verwendet.

Einheitliche Automatisierungs-Flags

Nutzen Sie dieses gemeinsame Flag-Modell in den Terraform-Variablen, um das Verhalten über CMF-Beispiele hinweg konsistent zu halten:

setup_project: Projektkontext erstellen oder verwenden.
setup_observability: Observability-Ressourcen aktivieren oder deaktivieren.
setup_database: Optionales VM-lokales PostgreSQL aktivieren oder deaktivieren.
setup_workload: Workload-Installation auf der VM aktivieren oder deaktivieren.
setup_loadgen: Optionale synthetische Lastgenerierung aktivieren oder deaktivieren.
setup_dns: Wird vom gemeinsamen Wrapper akzeptiert, ist in dieser Baseline aber nicht unterstützt.

Im aktuellen Rehost-Repository werden diese auf bestehende Schalter wie create_project, enable_observability, enable_local_postgresql und die Flags zur Lastgenerierung abgebildet.

Validierte Zielarchitektur

Das folgende Diagramm zeigt das implementierte und getestete Ziel, nicht eine zukünftige High-Availability-Variante.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie ein isoliertes Linux-Labor mit Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq und PostgreSQL-Server-/Client-Werkzeugen einschließlich pg_config. Die Sample-Dump-Skripte nutzen runuser und den lokalen OS-Account postgres und benötigen Root-Rechte in diesem Labor. Bei aktiviertem Server Backup braucht der Cutover zusätzlich eine authentifizierte STACKIT CLI. Verwenden Sie für vorhandene gespeicherte Pläne die Terraform-Version, die sie erzeugt hat; Plandateien sind versionsgebunden.

Beginnen Sie in einem übergeordneten Verzeichnis ohne bereits vorhandenen gleichnamigen Checkout. Dieser Stand enthält die Migrationsworkflows und die deklarative Observability-Verwaltung. Seine JAR ist gegenüber dem in der Replatform-Referenz fixierten Artefakt unverändert:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Führen Sie die folgenden Schritte erst nach erfolgreicher Vorbereitung aus diesem Checkout aus. Bewahren Sie vorhandene Checkouts, State und Nachweise, statt sie zu ersetzen. Halten Sie Credentials, Pläne, State, Dumps, Inventory und Nachweise privat und außerhalb der Versionsverwaltung; aktivieren Sie kein Shell-Tracing.

Zielparameter konfigurieren

Erstellen Sie die private Variablendatei nur, wenn sie noch nicht existiert:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie die Datei vor dem Plan. Konfigurieren Sie das freigegebene bestehende Projekt oder den Scope für die Projekterstellung, Service-Account-Key-Pfad, SSH-Schlüsselpaar, verfügbares Image, Availability Zone, VM-Flavor und Storage. Beschränken Sie SSH- und Applikations-Ingress auf die Quell-CIDRs, die am Zielpfad tatsächlich ankommen. Verifizieren Sie den SSH-Host-Key über einen vertrauenswürdigen Kanal, bevor Migrationsskripte die strikte Host-Prüfung verwenden. Setzen Sie für diese Skripte SSH_KEY und SSH_USER, falls sie von ~/.ssh/id_rsa und ubuntu abweichen; halten Sie sie konsistent zu private_ssh_key_path und ssh_user in Terraform.

Aktivieren Sie VM-lokales PostgreSQL, Observability und Server Backup für diesen Walkthrough. Lassen Sie für das erste Runtime-Deployment postgresql_restore_after_copy = false und den Quelldump-Pfad leer: Provisioning darf die Quelle nicht vor Probe und Cutover-Freigabe importieren. Übergeben Sie das Datenbankpasswort über den freigegebenen Secret-Mechanismus als TF_VAR_postgresql_app_password und bewahren Sie es für spätere Pläne sicher auf; schreiben Sie es nicht in Variablendatei, Shell-History oder Dokumentation.

Bestätigen Sie Berechtigungen, Quota, Kostenfreigabe und das private Terraform-Backend vor der Initialisierung. Dieser Ablauf setzt einen vorbereiteten Ausführungshost voraus und ist keine vollständige Installationsanleitung für das Labor.

Nachweise an der Quelle vorbereiten

Erstellen Sie einen Quelldump im Custom Format und erfassen Sie SHA-256-Prüfsumme, erwartete Datensatzanzahl und einen Workload-spezifischen deterministischen Fingerprint. Das Repository enthält ein reproduzierbares Beispiel mit acht Datensätzen:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

Das Validierungsskript stellt den Dump in einem separaten lokalen PostgreSQL-Cluster wieder her, bevor er in eine Migrationsprobe eingehen darf. Die Skripte erzeugen das mitgelieferte Sample in temporären lokalen Clustern; sie exportieren weder eine laufende Anwendung noch die STACKIT VM. Verwenden Sie ein frisches Artefaktverzeichnis und überschreiben Sie keinen bereits freigegebenen Migrationsdump. Exportieren Sie eine reale Quelle unter dem vereinbarten Write Freeze und erfassen Sie gleichwertige Nachweise für Prüfsumme, Anzahl und Fingerprint.

Ziel bereitstellen

Konfigurieren Sie ein bestehendes STACKIT Projekt oder die Projekterstellung, beschränken Sie SSH- und Applikations-Ingress auf freigegebene Quell-CIDRs und übergeben Sie das Datenbankpasswort über TF_VAR_postgresql_app_password statt über eine Variablendatei. Prüfen Sie vor dem Apply einen gespeicherten Plan.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stoppen Sie bei Fehlern in Initialisierung, Checks oder Plan. Prüfen Sie Ressourcenänderungen, Zielprojekt, Ingress, Kosten und den deaktivierten initialen Restore, bevor Sie den gespeicherten Plan ausdrücklich anwenden:

terraform apply tfplan

Terraform führt nach dem Provisioning Ansible aus. Ein erfolgreicher Apply belegt den Abschluss dieser Orchestrierung, nicht die Abnahme migrierter Daten. Prüfen Sie die Laufzeit vor der Probe:

./scripts/validate_deployment.sh

Migration proben

Führen Sie die Probe gegen eine temporäre Datenbank auf der Ziel-VM aus:

./scripts/run_migration_rehearsal.sh

Die Probe prüft die Quelldaten, stellt den Dump wieder her, vergleicht Datensatzanzahl und Fingerprint und entfernt die temporäre Datenbank, ohne die produktive springmusic-Datenbank zu verändern.

Cutover ausführen

Hinterlegen Sie die erwarteten Quelldaten in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Führen Sie anschließend das explizite Freigabe-Gate aus:

./scripts/run_cutover.sh --confirm

Das Skript verlangt ein vollständig verfügbares Server Backup, das höchstens 24 Stunden alt ist. Es erzeugt einen gespeicherten Terraform-Plan, der ausschließlich die Ansible-Orchestrierungsressource ersetzt, weist andere Infrastrukturänderungen zurück, führt den Restore aus, validiert Daten und Laufzeitverhalten und verlangt abschließend einen Terraform-No-op-Plan. Wiederholungen mit demselben Quelldump-Hash bewahren den ursprünglichen Datenbank-Rollback-Punkt.

Validieren und zurückrollen

Die Validierung prüft Datensatzanzahl und Fingerprint der Quelle, Tabellen-Ownership, einen transaktional zurückgerollten Schreibvorgang als Application Role, Erreichbarkeit der Anwendung, Services und den geschützten Rollback-Dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

Wenn innerhalb des Rollback-Fensters ein freigegebener Rollback-Trigger eintritt, bewahren Sie die aktuelle Zieldatenbank und stellen den ursprünglichen Dump von vor dem Cutover wieder her:

./scripts/rollback_postgresql.sh --confirm

Grenze zwischen Backup und Recovery

Mit enable_server_backup = true aktiviert Terraform STACKIT Server Backup und einen täglichen Zeitplan für das Boot Volume der VM. Die Standardaufbewahrung beträgt 14 Tage. Der Cutover verlangt ein vollständig verfügbares Backup, das höchstens 24 Stunden alt ist. Erstellung und Status des Backups wurden am realen Ziel validiert; ein In-place-Restore mit Server Backup bleibt eine disruptive Disaster-Recovery-Operation und muss in einer separaten Recovery-Umgebung geprobt werden.

Server Backup ergänzt den PostgreSQL-Dump von vor dem Restore. Es ersetzt weder die Datenbank-Konsistenzprüfungen noch das Application-Rollback-Verfahren.

Nutzung

Folgen Sie Arbeitsumgebung, privater Zielkonfiguration, Quellnachweisen und geprüftem Provisioning in dieser Reihenfolge. Proben Sie vor dem freigegebenen Cutover und bewahren Sie anschließend die Abnahmenachweise auf. Die Repository-Skripte rufen ausdrücklich terraform auf; ein Ausführungshost mit ausschließlich OpenTofu benötigt eine separat geprüfte Anpassung, nicht nur ersetzte Befehle auf dieser Seite.

Monitoring und Dashboard

Die Implementierung stellt STACKIT Observability bereit und erfasst den Node Exporter. Der Grafana-Provider verwaltet das enthaltene Dashboard im Ordner SCF Rehost mit der vorhandenen Thanos-Datenquelle. Er wartet auf die Bereitschaft der Instanz, statt die Dashboard-Erstellung stillschweigend zu überspringen.

Prüfen Sie über grafana_dashboard_url aktuelle VM-, Spring-Boot- und PostgreSQL-Metriken und verlangen Sie anschließend einen No-op-Plan. Sieben Panels bilden die aktive Basis ab; das Panel für synthetische Anfragen erscheint nur bei aktiviertem lokalem Lastgenerator. Diese Anfragen bilden nicht den gesamten Application-Traffic ab. Die Deployment-Validierung prüft außerdem Exporter-Metriken und Service Health nach dem Apply und nach dem Datenbank-Restore.

Die initialen Grafana-Admin-Zugangsdaten bleiben eine temporäre Authentifizierungsabhängigkeit. Schützen Sie State und gespeicherte Pläne. Benachrichtigungsempfänger, Zuständigkeit für Alarm-Routing, Application-Logs und Distributed Tracing benötigen vor Produktionseinsatz eine separate Konfiguration und Abnahme.

Ausrichtung an der Application Landing Zone

Dieses Beispiel kann in zwei zulässigen Setup-Modi eingesetzt werden.

Mit bestehender Application Landing Zone: Verwenden Sie den bereits definierten Projektkontext und Service Account Ihrer Landing-Zone-Implementierung. Nutzen Sie die bekannte Projekt-ID als Deployment-Ziel, zum Beispiel mit create_project = false und project_id = "...", sowie die für diesen Landing-Zone-Scope konfigurierte Service-Account-JSON.
Eigenständig ohne bestehendes Landing-Zone-Projekt: Lassen Sie das Beispiel ein dediziertes Projekt erstellen. Setzen Sie create_project = true und geben Sie über parent_container_id einen bestehenden Folder oder Container an, in dem der Service Account ausreichende Berechtigungen hat.

Hinweise zum Landing-Zone-Design finden Sie unter Application Landing Zone.

Minimales Konfigurationsbeispiel

Nutzen Sie dieses Beispiel als Ausgangspunkt in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone           = "eu01-1"
machine_type                = "g2i.2"
ssh_allowed_cidr            = "203.0.113.10/32"
app_allowed_cidr            = "203.0.113.10/32"
enable_local_postgresql     = true
enable_observability       = true
enable_server_backup       = true

Verhalten des Deployment-Artefakts

Standard-Artefaktpfad: ansible/files/springboot-app.jar
Standardvariable: jar_local_path verweist auf dieselbe Datei.
Alternatives Artefakt: Ersetzen Sie die Datei oder überschreiben Sie jar_local_path.

Wenn sich das Artefakt ändert, erkennt Terraform die geänderte Prüfsumme und führt den Ansible-Deployment-Schritt erneut aus.

Nachweise und Abnahme

Jede Probe, jeder Cutover und jedes Rollback schreibt eine evidence.env-Datei unter artifacts/evidence/<timestamp>-<mode>/. Akzeptieren Sie einen Cutover nur, wenn der Nachweis die erwartete Prüfsumme, Datensatzanzahl, den Fingerprint, die Ziel-VM, eine erfolgreiche Laufzeitvalidierung und den abschließenden Terraform-No-op dokumentiert.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Verwenden Sie denselben freigegebenen Quellpfad, Restore-Schalter, Erwartungswert und Fingerprint wie beim abgeschlossenen Cutover. Exit-Code 0 bedeutet keine Änderungen, 2 vorgeschlagene Änderungen und 1 einen Fehler. Ein Plan allein belegt keinen Apply. Der Cutover-Workflow setzt status=passed und terraform_noop=true erst nach Anwendung seines gespeicherten Plans und erfolgreicher Daten- und Laufzeitvalidierung.

Entscheidungs- und Freigabepunkte der Migration

Vorbereiten: Zieldesign, Zugangswege, Quellnachweise und Recovery-Verantwortung freigeben.
Bereitstellen: Infrastrukturplan prüfen und anwenden, danach die VM-Laufzeit unabhängig verifizieren.
Proben: In einer isolierten Datenbank wiederherstellen und Integrität prüfen, ohne die Anwendungsdatenbank zu verändern.
Umschalten: Schreibzugriffe an der Quelle einfrieren, finalen Dump freigeben und ausschließlich die vorgesehene Orchestrierungsänderung zulassen.
Abnehmen oder wiederherstellen: Daten-, Laufzeit- und No-op-Nachweise verlangen; bei fehlgeschlagener Abnahme das vereinbarte Rollback vor der Deadline auslösen.
Übergeben: Monitoring, Backup-Ownership, Nachweise und Entscheidungen zur Quellenaufbewahrung vor Optimize übergeben.

Als Replatform-Basis weiterverwenden

Die Replatform-Referenz verwendet das fixierte Spring-Music-JAR und den Sample-Datengenerator dieses Repositories weiter. Ihr Sample-Walkthrough benötigt deshalb diesen Checkout und validierte Dump-Artefakte, aber keine neu bereitgestellte Rehost-VM. Erstellen Sie keine zusätzliche VM allein zur Erzeugung des lokalen Samples.

Für eine tatsächliche Migration von der Rehost-VM zu SKE und PostgreSQL Flex müssen Sie den aktuellen VM-Zustand prüfen, Schreibzugriffe der Anwendung einfrieren, die reale PostgreSQL-Datenbank exportieren und diesen Export qualifizieren. Ein historisch erfolgreicher Rehost-Apply belegt weder aktuelle Erreichbarkeit noch die Gleichwertigkeit des lokalen Samples mit den VM-Daten. Quellexport, Abnahme und Source Failback benötigen ein eigenes freigegebenes Verfahren.

Hinweise

Stimmen Sie Betriebsverfahren mit Runbook und Migration Governance ab.
Passen Sie für den Produktionseinsatz Sicherheitskontrollen, Sizing, Image-Auswahl und Lifecycle-Automatisierung an.

GOAL

Optimierung

Kehren Sie vom konkreten Migrationsbeispiel zum Migration Framework zurück. Beginnen Sie Optimize erst nach stabilem Cutover, verwenden Sie repräsentative Produktionstelemetrie, setzen Sie jeweils eine kontrollierte Änderung um und validieren Sie ihre Wirkung auf Zuverlässigkeit, Performance und Kosten.

In 7 Trails

Überblick: Optimize-Modul

Optimize startet, sobald Workloads auf STACKIT laufen und reale Daten aus dem Betrieb vorliegen. Das Modul überführt Beobachtungen aus dem Betrieb in messbare Verbesserungen für Performance, Stabilität und Wirtschaftlichkeit.

Optimize ist keine einmalige Aufgabe, sondern ein iterativer Zyklus, der sich mit früher Stabilisierung und Unterstützung direkt nach dem Cutover überschneiden kann.

Warum Optimize nach dem Cutover liegt

Viele Entscheidungen zu Rightsizing und Tuning sind erst unter echter Last belastbar. Nach dem Cutover lassen sich Annahmen mit Daten aus dem Betrieb validieren und präzisieren.

Optimize-Zyklus

Laufzeitdaten erfassen: Auslastung, Latenz, Fehlerquoten, Durchsatz und Kostentreiber.
Engpässe und Verschwendungsmuster auf Workload-, Plattform- und Datenebene identifizieren.
Maßnahmen nach Business-Effekt, Risikoreduktion und FinOps-Nutzen priorisieren.
Tuning-Änderungen in kontrollierten Inkrementen umsetzen.
Ergebnisse gegen SLO-, Stabilitäts- und Kostenziele validieren.
Erkenntnisse in Folgewellen und Betriebsstandards zurückführen.

Typische Bereiche

Rightsizing: Compute-, Storage- und Netzwerkressourcen an reale Last anpassen.
Performance-Tuning: Latenz und Durchsatz durch Konfiguration, Skalierung und Architekturmaßnahmen verbessern.
Reliability-Hardening: Incident-Häufigkeit durch Resilienz-, Monitoring- und Fehlerbehandlungsmaßnahmen reduzieren.
FinOps-Steuerung: Kostentransparenz verbessern, Verschwendung abbauen und Run-Rate optimieren.

Von der Theorie zur Umsetzung

Optimierungsentscheidungen sollten auf Laufzeitdaten basieren, nicht auf Annahmen. Für die praktische Umsetzung werden Workload-Telemetrie, Alerting und kontrollierte Infrastrukturänderungen kombiniert.

Managed-Observability-Basis: Mit STACKIT Observability Metriken, Logs und Traces mit Grafana, Prometheus, Thanos, Loki und Tempo erfassen.
Erkennungslogik: Klare Schwellwerte und Beobachtungsfenster für Unterauslastung und Überlast definieren.
Umsetzungspfad: Rightsizing über IaC-Änderungen (zum Beispiel VM-Flavors) mit Rollback-Checkpoints umsetzen.
Validierungsschleife: Nach jedem Tuning-Inkrement SLO, Fehlerquote und Laufkosten erneut messen.

Konkrete Beispiel-Assets

Asset-Titel

Framework

Asset-Typ

Migration migrate optimize rehost observability +2

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

STACKIT

Migration design-and-mobilize use-cases migrate optimize +6

Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC.

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

Migration

Runbook

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

STACKIT

Migration migrate optimize replatform cloud-foundry +3

Dasselbe Spring-Boot-Replatform anhand gemessener Pod- und Node-Kapazität, PostgreSQL-Flex-Tuning, Skalierungsleitplanken und reversibler Änderungen optimieren.

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

Migration

Runbook

Replatform Spring Boot auf Cloud Foundry mit Autoscaling und Rightsizing optimieren

STACKIT

Open Source

Praktisches Optimize-Runbook für einen auf STACKIT Cloud Foundry migrierten Spring-Boot-Workload mit Observability-Signalen, Autoscaling und Validierung.

Replatform Spring Boot auf Cloud Foundry mit Autoscaling und Rightsizing optimieren

Migration

Runbook

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

STACKIT

Migration migrate optimize relocate vm +3

Open Source In 1 Trail

Dimensioniert verlagerte STACKIT VMs anhand repräsentativer Telemetrie neu, mit kontrollierten Machine-Type-Änderungen, Storage-Migration, Validierung und Rollback.

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

Migration

Runbook

Replatform-Optimierungsdimensionen

Für Replatform-Workloads auf Kubernetes umfasst Optimierung mehrere Ebenen und sollte als gemeinsamer Regelkreis gesteuert werden.

Pod-Skalierung: HPA nutzen, um die Replikazahl anhand von Last mit klaren Min-/Max-Grenzen anzupassen.
Node-Pool-Skalierung: Ausreichend Cluster-Headroom sicherstellen und den Maschinentyp (Flavor) für CPU-/Memory-Dichteanforderungen abstimmen.
Ingress-Skalierung: Den Serviceplan des Load Balancers neu bewerten, wenn Ingress-Durchsatz oder Verbindungsverhalten zum Engpass werden.
Storage-Rightsizing: Storage-Klassen nach Performance-Anforderungen persistenter Workloads auswählen.
Validierungsdisziplin: Nach jeder inkrementellen Tuning-Änderung Latenz, Fehlerquote und Kosten erneut prüfen.

Eingaben und Ergebnisse

Zentrale Eingaben

Cutover-Berichte, Incident-Trends, SLO-Messwerte, Telemetrie-Baselines und Kostenberichte.

Ergebnisse

Priorisiertes Verbesserungs-Backlog, validierte Tuning-Änderungen und aktualisierte Betriebsstandards.

Governance-Effekt

Nachvollziehbare Trade-off-Entscheidungen zwischen Performance, Stabilität und Kosten.

Abgrenzung zu anderen Modulen

Optimize folgt auf die technische Umsetzung in Migrate.
Aktivitäten direkt nach dem Cutover können parallel laufen, die fachliche Verankerung erfolgt jedoch in der Run-Phase.
Umfassende Umbauten bleiben im Modul Refactor.

OPS

Dieselbe Referenzimplementierung fortsetzen

Migration migrate optimize rehost observability rightsizing spring-boot

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

STACKIT

Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Arbeiten Sie mit derselben Terraform- und Ansible-Referenzimplementierung weiter, die in den vorherigen Rehost-Migrationsschritten verwendet wurde. Repository öffnen Rehost-Implementierungs-Asset

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Dieselbe Referenzimplementierung fortsetzen

Dieses Asset führt dieselbe Spring-Boot- und PostgreSQL-Referenzimplementierung fort, die für Provisioning, Migration, Cutover und Stabilisierung verwendet wurde. Es führt kein weiteres Beispiel oder Repository ein. Die vorhandenen Terraform-Variablen, Ansible-Konfiguration, Observability-Instanz und Validierungsworkflows bleiben die technische Baseline für Optimize.

Die Optimize-Erweiterung beantwortet eine praktische Frage: Wie lassen sich Über- oder Unterprovisionierung erkennen und VM- oder Storage-Kapazität anschließend über einen kontrollierten IaC-Workflow ändern?

Observability-Setup für die Optimierung

Nutze den managed STACKIT Observability -Stack als Datenquelle.

Prometheus: Metrik-Erfassung
Thanos: Langfristige Aufbewahrung von Metriken
Grafana Loki: Log-Analyse
Grafana Tempo: Distributed Traces
Grafana: Dashboards und Visualisierung

Architektur-Referenzen:

Observability-Entscheidungsdashboard

Nutze das Dashboard, um Infrastruktur-Auslastung, Anwendungszustand, Request-Verhalten und Alert-Historie gemeinsam zu bewerten, bevor die VM-Kapazität geändert wird.

Grafana-Dashboard für die Observability eines Rehost-Spring-Boot-Workloads und VM-Rightsizing-Entscheidungen

Signale und Schwellwerte für Rightsizing

Definiere technische Schwellwerte, bevor du Kapazität änderst.

Kandidat für Downsize: CPU p95 unter 30% und Memory p95 unter 50% für mindestens 14 Tage.
Kandidat für Scale-up: CPU p95 über 75% oder Memory p95 über 80% während Business-Lastfenstern für mindestens drei Tage in Folge.
Stabilitäts-Guardrail: Keine offenen kritischen Alerts und keine Regression in der Error-Rate-SLO.

Halte Schwellwerte workload-spezifisch und validiere sie gegen reale Traffic-Muster.

Datenbank Sicht für Optimize Entscheidungen

Für stateful Rehost-Workloads sollten Signale aus der Datenbank im selben Dashboard-Zyklus bewertet werden.

Verbindungen: Trend aktiver Verbindungen und Verhalten bei Lastspitzen.
Datenbank Größe: Entwicklung der Datenbankgröße über die Zeit.
Transaktionen: Commit-/Rollback-Trends zur Stabilitätsbewertung.

Nutze diese Signale gemeinsam mit VM-Metriken, damit Optimize-Entscheidungen nicht nur auf CPU oder Memory basieren.

PostgreSQL Flex im späteren Optimize-Pfad

Wenn der Rehost-Workload den Datenbank-Layer später auf PostgreSQL Flex umstellt, sollte DB-Rightsizing in denselben Optimize-Loop aufgenommen werden.

Ziel-Instanz planen: PostgreSQL-Flex-Instanz planen
Flavor und Performance-Klasse abstimmen: Flavors und Performance-Klassen von PostgreSQL Flex
Integriertes Dashboard für schnelle Prüfung: Dashboard-Metriken
Observability-Metriken für Analyse im Detail: Observability-Metriken

Rightsizing-Workflow

Baseline-Metriken und Traces für einen repräsentativen Zeitraum erfassen.
Optimize-Kandidat mit Dashboards und Alert-Historie bestätigen.
Kapazitätsänderung und Rollback-Checkpoint planen.
VM-Größe per Terraform/OpenTofu anpassen.
Latenz, Error-Rates, Durchsatz und Kosten erneut validieren.
Behalten oder zurückrollen anhand objektiver Kriterien.

Praktisches Beispiel

Beispiel A: Downsize nach dauerhaft niedriger Auslastung

Passe die VM-Größe in env.tfvars an:

machine_type = "g3i.2"

Apply und Plan-Ausgabe prüfen:

terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars

Danach validieren:

Service-Health (systemctl status, synthetische Checks)
p95-Latenz und Error-Rate-Trend
Kosten-Differenz im Reporting-Zeitraum

Beispiel B: Scale-up bei dauerhaft hoher Last

Passe die VM-Größe in env.tfvars an:

machine_type = "g3i.4"

Apply durchführen und mit denselben Post-Change-Checks validieren.

Rollback-Muster

Wenn sich SLOs nach dem Rightsizing verschlechtern, rolle zurück, indem du den vorherigen machine_type wiederherstellst und IaC erneut ausführst. Behandle Rollback als regulären Runbook-Schritt und nicht nur als Notfallweg.

Hinweise

Abhängig von Plattform-Constraints und Machine Type kann ein Resize einen Neustart oder Ersatz der VM auslösen. Prüfe das Verhalten vorab in terraform plan.

Storage als Optimierungsaspekt

In Rehost-Szenarien sind CPU und Memory nur eine Seite des Rightsizing. Auch Storage-Performance kann zum Engpass werden.

Wann Storage prüfen: erhöhte I/O-Wait-Werte, instabile Latenz bei schreibintensiver Last oder Throughput-Sättigung trotz freier CPU.
Was auswählen: Storage-Service-Plan und Performance-Klasse passend zum beobachteten IOPS- und Durchsatzprofil.
Guidance: Block Storage Service Plans

Performance-Klasse vor dem Provisioning auswählen

Eine Block-Storage-Performance-Klasse definiert die maximalen IOPS und den maximalen Durchsatz für das gesamte Volume. Zugriffe von Anwendung, Datenbank, Betriebssystem und Backup teilen dieses Performance-Budget. Wählen Sie die Klasse vor dem Erstellen des Volumes anhand gemessener Lastspitzen, Latenzanforderungen, Backup-Aktivität und expliziter Wachstumsreserve.

Aus der STACKIT-DokuService-Pläne › Derzeit verfügbare Servicepläne (Leistungs-Klassen)Stand der Quelle 20.01.2026 · übernommen 05.10.2026

Die folgende Tabelle listet die derzeit verfügbaren Leistungs-Klassen für die Region EU01 auf:

Seitlich wischen, um die ganze Tabelle zu sehen

Leistungs-Klasse	Name	Max. IOPS	Max. Durchsatz (MB/s)
Leistungs-Klasse 0	storage_premium_perf0	120	25
Leistungs-Klasse 1	storage_premium_perf1	500	50
Leistungs-Klasse 2	storage_premium_perf2	1000	100
Leistungs-Klasse 4	storage_premium_perf4	2000	150
Leistungs-Klasse 6	storage_premium_perf6	5000	200
Leistungs-Klasse 8	storage_premium_perf8	10000	250
Leistungs-Klasse 10	storage_premium_perf10	15000	300
Leistungs-Klasse 12	storage_premium_perf12	20000	350
Leistungs-Klasse 13	storage_premium_perf13	20000	700
Leistungs-Klasse 14	storage_premium_perf14	25000	400
Leistungs-Klasse 15	storage_premium_perf15	25000	800
Leistungs-Klasse 16	storage_premium_perf16	30000	450
Leistungs-Klasse 17	storage_premium_perf17	30000	900
Leistungs-Klasse 18	storage_premium_perf18	35000	500
Leistungs-Klasse 19	storage_premium_perf19	35000	1000
Leistungs-Klasse 20	storage_premium_perf20	40000	550
Leistungs-Klasse 21	storage_premium_perf21	40000	1100

IOPS – Input/Output Operations per second (Ein-/Ausgabebefehle pro Sekunde)

Durchsatz – Durchsatz in Megabyte pro Sekunde

Somit lassen sich die verwendeten Klassen anhand der Namensgebung im Detail unterscheiden. Beispiel: „Block Storage Premium – Leistungs-Klasse 2“ entspricht SSD-Festplatten mit max. 1000 IOPS und max. 100 Mbyte/s Durchsatz.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

In der Rehost-Baseline teilen sich Betriebssystem, Spring-Boot-Anwendung und PostgreSQL-Daten das Boot Volume. Eine Änderung der Performance-Klasse erfordert daher ein kontrolliertes Ersatzziel:

Wählen Sie die neue Klasse anhand beobachteter IOPS, Durchsatz-, Latenz- und I/O-Wait-Werte.
Prüfen Sie die Bereitschaft für Backup und Datenbank-Rollback.
Stellen Sie Ersatz-VM und Boot Volume mit der gewählten Klasse über IaC bereit.
Wenden Sie die Ansible-Konfiguration erneut an und stellen oder migrieren Sie die Workload-Daten wieder her.
Validieren Sie vor der Umschaltung Applikationsverhalten, Datenintegrität, Storage-Latenz, Backup-Abdeckung und Kosten.

Verwenden Sie ein separates Data Volume, wenn Storage-Kapazität oder -Performance unabhängig vom VM-Lifecycle weiterentwickelt werden müssen. Erstellen Sie für eine andere Performance-Klasse ein neues Volume im erforderlichen Verfügbarkeitsmodell mit ausreichender Kapazität, stoppen Sie Schreibzugriffe, migrieren und verifizieren Sie die Daten, wechseln Sie Attachment oder Mount und bewahren Sie das Quell-Volume auf, bis Abnahme- und Rollback-Gates passiert sind.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Arbeiten Sie mit derselben Terraform- und Ansible-Referenzimplementierung weiter, die in den vorherigen Rehost-Migrationsschritten verwendet wurde. Repository öffnen Rehost-Implementierungs-Asset

Behandeln Sie Storage-Prüfungen als Teil derselben Optimize-Schleife und validieren Sie nach jeder Änderung erneut Latenz, Fehlerverhalten, Recovery und Kostenwirkung.

Dieselbe Referenzimplementierung fortsetzen

Dieses Asset führt dieselbe Spring-Boot- und PostgreSQL-Referenzimplementierung fort, die für Provisioning, Migration, Cutover und Stabilisierung verwendet wurde. Es führt kein weiteres Beispiel oder Repository ein. Die vorhandenen Terraform-Variablen, Ansible-Konfiguration, Observability-Instanz und Validierungsworkflows bleiben die technische Baseline für Optimize.

Die Optimize-Erweiterung beantwortet eine praktische Frage: Wie lassen sich Über- oder Unterprovisionierung erkennen und VM- oder Storage-Kapazität anschließend über einen kontrollierten IaC-Workflow ändern?

Observability-Setup für die Optimierung

Nutze den managed STACKIT Observability -Stack als Datenquelle.

Prometheus: Metrik-Erfassung
Thanos: Langfristige Aufbewahrung von Metriken
Grafana Loki: Log-Analyse
Grafana Tempo: Distributed Traces
Grafana: Dashboards und Visualisierung

Architektur-Referenzen:

Observability-Entscheidungsdashboard

Nutze das Dashboard, um Infrastruktur-Auslastung, Anwendungszustand, Request-Verhalten und Alert-Historie gemeinsam zu bewerten, bevor die VM-Kapazität geändert wird.

Signale und Schwellwerte für Rightsizing

Definiere technische Schwellwerte, bevor du Kapazität änderst.

Kandidat für Downsize: CPU p95 unter 30% und Memory p95 unter 50% für mindestens 14 Tage.
Kandidat für Scale-up: CPU p95 über 75% oder Memory p95 über 80% während Business-Lastfenstern für mindestens drei Tage in Folge.
Stabilitäts-Guardrail: Keine offenen kritischen Alerts und keine Regression in der Error-Rate-SLO.

Halte Schwellwerte workload-spezifisch und validiere sie gegen reale Traffic-Muster.

Datenbank Sicht für Optimize Entscheidungen

Für stateful Rehost-Workloads sollten Signale aus der Datenbank im selben Dashboard-Zyklus bewertet werden.

Verbindungen: Trend aktiver Verbindungen und Verhalten bei Lastspitzen.
Datenbank Größe: Entwicklung der Datenbankgröße über die Zeit.
Transaktionen: Commit-/Rollback-Trends zur Stabilitätsbewertung.

Nutze diese Signale gemeinsam mit VM-Metriken, damit Optimize-Entscheidungen nicht nur auf CPU oder Memory basieren.

PostgreSQL Flex im späteren Optimize-Pfad

Wenn der Rehost-Workload den Datenbank-Layer später auf PostgreSQL Flex umstellt, sollte DB-Rightsizing in denselben Optimize-Loop aufgenommen werden.

Ziel-Instanz planen: PostgreSQL-Flex-Instanz planen
Flavor und Performance-Klasse abstimmen: Flavors und Performance-Klassen von PostgreSQL Flex
Integriertes Dashboard für schnelle Prüfung: Dashboard-Metriken
Observability-Metriken für Analyse im Detail: Observability-Metriken

Rightsizing-Workflow

Baseline-Metriken und Traces für einen repräsentativen Zeitraum erfassen.
Optimize-Kandidat mit Dashboards und Alert-Historie bestätigen.
Kapazitätsänderung und Rollback-Checkpoint planen.
VM-Größe per Terraform/OpenTofu anpassen.
Latenz, Error-Rates, Durchsatz und Kosten erneut validieren.
Behalten oder zurückrollen anhand objektiver Kriterien.

Praktisches Beispiel

Beispiel A: Downsize nach dauerhaft niedriger Auslastung

Passe die VM-Größe in env.tfvars an:

machine_type = "g3i.2"

Apply und Plan-Ausgabe prüfen:

terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars

Danach validieren:

Service-Health (systemctl status, synthetische Checks)
p95-Latenz und Error-Rate-Trend
Kosten-Differenz im Reporting-Zeitraum

Beispiel B: Scale-up bei dauerhaft hoher Last

Passe die VM-Größe in env.tfvars an:

machine_type = "g3i.4"

Apply durchführen und mit denselben Post-Change-Checks validieren.

Rollback-Muster

Wenn sich SLOs nach dem Rightsizing verschlechtern, rolle zurück, indem du den vorherigen machine_type wiederherstellst und IaC erneut ausführst. Behandle Rollback als regulären Runbook-Schritt und nicht nur als Notfallweg.

Hinweise

Abhängig von Plattform-Constraints und Machine Type kann ein Resize einen Neustart oder Ersatz der VM auslösen. Prüfe das Verhalten vorab in terraform plan.

Storage als Optimierungsaspekt

In Rehost-Szenarien sind CPU und Memory nur eine Seite des Rightsizing. Auch Storage-Performance kann zum Engpass werden.

Wann Storage prüfen: erhöhte I/O-Wait-Werte, instabile Latenz bei schreibintensiver Last oder Throughput-Sättigung trotz freier CPU.
Was auswählen: Storage-Service-Plan und Performance-Klasse passend zum beobachteten IOPS- und Durchsatzprofil.
Guidance: Block Storage Service Plans

Performance-Klasse vor dem Provisioning auswählen

Eine Block-Storage-Performance-Klasse definiert die maximalen IOPS und den maximalen Durchsatz für das gesamte Volume. Zugriffe von Anwendung, Datenbank, Betriebssystem und Backup teilen dieses Performance-Budget. Wählen Sie die Klasse vor dem Erstellen des Volumes anhand gemessener Lastspitzen, Latenzanforderungen, Backup-Aktivität und expliziter Wachstumsreserve.

Aus der STACKIT-DokuService-Pläne › Derzeit verfügbare Servicepläne (Leistungs-Klassen)Stand der Quelle 20.01.2026 · übernommen 05.10.2026

Die folgende Tabelle listet die derzeit verfügbaren Leistungs-Klassen für die Region EU01 auf:

Seitlich wischen, um die ganze Tabelle zu sehen

Leistungs-Klasse	Name	Max. IOPS	Max. Durchsatz (MB/s)
Leistungs-Klasse 0	storage_premium_perf0	120	25
Leistungs-Klasse 1	storage_premium_perf1	500	50
Leistungs-Klasse 2	storage_premium_perf2	1000	100
Leistungs-Klasse 4	storage_premium_perf4	2000	150
Leistungs-Klasse 6	storage_premium_perf6	5000	200
Leistungs-Klasse 8	storage_premium_perf8	10000	250
Leistungs-Klasse 10	storage_premium_perf10	15000	300
Leistungs-Klasse 12	storage_premium_perf12	20000	350
Leistungs-Klasse 13	storage_premium_perf13	20000	700
Leistungs-Klasse 14	storage_premium_perf14	25000	400
Leistungs-Klasse 15	storage_premium_perf15	25000	800
Leistungs-Klasse 16	storage_premium_perf16	30000	450
Leistungs-Klasse 17	storage_premium_perf17	30000	900
Leistungs-Klasse 18	storage_premium_perf18	35000	500
Leistungs-Klasse 19	storage_premium_perf19	35000	1000
Leistungs-Klasse 20	storage_premium_perf20	40000	550
Leistungs-Klasse 21	storage_premium_perf21	40000	1100

IOPS – Input/Output Operations per second (Ein-/Ausgabebefehle pro Sekunde)

Durchsatz – Durchsatz in Megabyte pro Sekunde

Somit lassen sich die verwendeten Klassen anhand der Namensgebung im Detail unterscheiden. Beispiel: „Block Storage Premium – Leistungs-Klasse 2“ entspricht SSD-Festplatten mit max. 1000 IOPS und max. 100 Mbyte/s Durchsatz.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

In der Rehost-Baseline teilen sich Betriebssystem, Spring-Boot-Anwendung und PostgreSQL-Daten das Boot Volume. Eine Änderung der Performance-Klasse erfordert daher ein kontrolliertes Ersatzziel:

Wählen Sie die neue Klasse anhand beobachteter IOPS, Durchsatz-, Latenz- und I/O-Wait-Werte.
Prüfen Sie die Bereitschaft für Backup und Datenbank-Rollback.
Stellen Sie Ersatz-VM und Boot Volume mit der gewählten Klasse über IaC bereit.
Wenden Sie die Ansible-Konfiguration erneut an und stellen oder migrieren Sie die Workload-Daten wieder her.
Validieren Sie vor der Umschaltung Applikationsverhalten, Datenintegrität, Storage-Latenz, Backup-Abdeckung und Kosten.

Verwenden Sie ein separates Data Volume, wenn Storage-Kapazität oder -Performance unabhängig vom VM-Lifecycle weiterentwickelt werden müssen. Erstellen Sie für eine andere Performance-Klasse ein neues Volume im erforderlichen Verfügbarkeitsmodell mit ausreichender Kapazität, stoppen Sie Schreibzugriffe, migrieren und verifizieren Sie die Daten, wechseln Sie Attachment oder Mount und bewahren Sie das Quell-Volume auf, bis Abnahme- und Rollback-Gates passiert sind.

Behandeln Sie Storage-Prüfungen als Teil derselben Optimize-Schleife und validieren Sie nach jeder Änderung erneut Latenz, Fehlerverhalten, Recovery und Kostenwirkung.

OPS

VM-Flavor richtig dimensionieren

Migration migrate optimize rehost observability rightsizing spring-boot

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

STACKIT

Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Arbeiten Sie mit derselben Terraform- und Ansible-Referenzimplementierung weiter, die in den vorherigen Rehost-Migrationsschritten verwendet wurde. Repository öffnen Rehost-Implementierungs-Asset

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Dieselbe Referenzimplementierung fortsetzen

Dieses Asset führt dieselbe Spring-Boot- und PostgreSQL-Referenzimplementierung fort, die für Provisioning, Migration, Cutover und Stabilisierung verwendet wurde. Es führt kein weiteres Beispiel oder Repository ein. Die vorhandenen Terraform-Variablen, Ansible-Konfiguration, Observability-Instanz und Validierungsworkflows bleiben die technische Baseline für Optimize.

Die Optimize-Erweiterung beantwortet eine praktische Frage: Wie lassen sich Über- oder Unterprovisionierung erkennen und VM- oder Storage-Kapazität anschließend über einen kontrollierten IaC-Workflow ändern?

Observability-Setup für die Optimierung

Nutze den managed STACKIT Observability -Stack als Datenquelle.

Prometheus: Metrik-Erfassung
Thanos: Langfristige Aufbewahrung von Metriken
Grafana Loki: Log-Analyse
Grafana Tempo: Distributed Traces
Grafana: Dashboards und Visualisierung

Architektur-Referenzen:

Observability-Entscheidungsdashboard

Nutze das Dashboard, um Infrastruktur-Auslastung, Anwendungszustand, Request-Verhalten und Alert-Historie gemeinsam zu bewerten, bevor die VM-Kapazität geändert wird.

Signale und Schwellwerte für Rightsizing

Definiere technische Schwellwerte, bevor du Kapazität änderst.

Kandidat für Downsize: CPU p95 unter 30% und Memory p95 unter 50% für mindestens 14 Tage.
Kandidat für Scale-up: CPU p95 über 75% oder Memory p95 über 80% während Business-Lastfenstern für mindestens drei Tage in Folge.
Stabilitäts-Guardrail: Keine offenen kritischen Alerts und keine Regression in der Error-Rate-SLO.

Halte Schwellwerte workload-spezifisch und validiere sie gegen reale Traffic-Muster.

Datenbank Sicht für Optimize Entscheidungen

Für stateful Rehost-Workloads sollten Signale aus der Datenbank im selben Dashboard-Zyklus bewertet werden.

Verbindungen: Trend aktiver Verbindungen und Verhalten bei Lastspitzen.
Datenbank Größe: Entwicklung der Datenbankgröße über die Zeit.
Transaktionen: Commit-/Rollback-Trends zur Stabilitätsbewertung.

Nutze diese Signale gemeinsam mit VM-Metriken, damit Optimize-Entscheidungen nicht nur auf CPU oder Memory basieren.

PostgreSQL Flex im späteren Optimize-Pfad

Wenn der Rehost-Workload den Datenbank-Layer später auf PostgreSQL Flex umstellt, sollte DB-Rightsizing in denselben Optimize-Loop aufgenommen werden.

Ziel-Instanz planen: PostgreSQL-Flex-Instanz planen
Flavor und Performance-Klasse abstimmen: Flavors und Performance-Klassen von PostgreSQL Flex
Integriertes Dashboard für schnelle Prüfung: Dashboard-Metriken
Observability-Metriken für Analyse im Detail: Observability-Metriken

Rightsizing-Workflow

Baseline-Metriken und Traces für einen repräsentativen Zeitraum erfassen.
Optimize-Kandidat mit Dashboards und Alert-Historie bestätigen.
Kapazitätsänderung und Rollback-Checkpoint planen.
VM-Größe per Terraform/OpenTofu anpassen.
Latenz, Error-Rates, Durchsatz und Kosten erneut validieren.
Behalten oder zurückrollen anhand objektiver Kriterien.

Praktisches Beispiel

Beispiel A: Downsize nach dauerhaft niedriger Auslastung

Passe die VM-Größe in env.tfvars an:

machine_type = "g3i.2"

Apply und Plan-Ausgabe prüfen:

terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars

Danach validieren:

Service-Health (systemctl status, synthetische Checks)
p95-Latenz und Error-Rate-Trend
Kosten-Differenz im Reporting-Zeitraum

Beispiel B: Scale-up bei dauerhaft hoher Last

Passe die VM-Größe in env.tfvars an:

machine_type = "g3i.4"

Apply durchführen und mit denselben Post-Change-Checks validieren.

Rollback-Muster

Wenn sich SLOs nach dem Rightsizing verschlechtern, rolle zurück, indem du den vorherigen machine_type wiederherstellst und IaC erneut ausführst. Behandle Rollback als regulären Runbook-Schritt und nicht nur als Notfallweg.

Hinweise

Abhängig von Plattform-Constraints und Machine Type kann ein Resize einen Neustart oder Ersatz der VM auslösen. Prüfe das Verhalten vorab in terraform plan.

Storage als Optimierungsaspekt

In Rehost-Szenarien sind CPU und Memory nur eine Seite des Rightsizing. Auch Storage-Performance kann zum Engpass werden.

Wann Storage prüfen: erhöhte I/O-Wait-Werte, instabile Latenz bei schreibintensiver Last oder Throughput-Sättigung trotz freier CPU.
Was auswählen: Storage-Service-Plan und Performance-Klasse passend zum beobachteten IOPS- und Durchsatzprofil.
Guidance: Block Storage Service Plans

Performance-Klasse vor dem Provisioning auswählen

Eine Block-Storage-Performance-Klasse definiert die maximalen IOPS und den maximalen Durchsatz für das gesamte Volume. Zugriffe von Anwendung, Datenbank, Betriebssystem und Backup teilen dieses Performance-Budget. Wählen Sie die Klasse vor dem Erstellen des Volumes anhand gemessener Lastspitzen, Latenzanforderungen, Backup-Aktivität und expliziter Wachstumsreserve.

Aus der STACKIT-DokuService-Pläne › Derzeit verfügbare Servicepläne (Leistungs-Klassen)Stand der Quelle 20.01.2026 · übernommen 05.10.2026

Die folgende Tabelle listet die derzeit verfügbaren Leistungs-Klassen für die Region EU01 auf:

Seitlich wischen, um die ganze Tabelle zu sehen

Leistungs-Klasse	Name	Max. IOPS	Max. Durchsatz (MB/s)
Leistungs-Klasse 0	storage_premium_perf0	120	25
Leistungs-Klasse 1	storage_premium_perf1	500	50
Leistungs-Klasse 2	storage_premium_perf2	1000	100
Leistungs-Klasse 4	storage_premium_perf4	2000	150
Leistungs-Klasse 6	storage_premium_perf6	5000	200
Leistungs-Klasse 8	storage_premium_perf8	10000	250
Leistungs-Klasse 10	storage_premium_perf10	15000	300
Leistungs-Klasse 12	storage_premium_perf12	20000	350
Leistungs-Klasse 13	storage_premium_perf13	20000	700
Leistungs-Klasse 14	storage_premium_perf14	25000	400
Leistungs-Klasse 15	storage_premium_perf15	25000	800
Leistungs-Klasse 16	storage_premium_perf16	30000	450
Leistungs-Klasse 17	storage_premium_perf17	30000	900
Leistungs-Klasse 18	storage_premium_perf18	35000	500
Leistungs-Klasse 19	storage_premium_perf19	35000	1000
Leistungs-Klasse 20	storage_premium_perf20	40000	550
Leistungs-Klasse 21	storage_premium_perf21	40000	1100

IOPS – Input/Output Operations per second (Ein-/Ausgabebefehle pro Sekunde)

Durchsatz – Durchsatz in Megabyte pro Sekunde

Somit lassen sich die verwendeten Klassen anhand der Namensgebung im Detail unterscheiden. Beispiel: „Block Storage Premium – Leistungs-Klasse 2“ entspricht SSD-Festplatten mit max. 1000 IOPS und max. 100 Mbyte/s Durchsatz.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

In der Rehost-Baseline teilen sich Betriebssystem, Spring-Boot-Anwendung und PostgreSQL-Daten das Boot Volume. Eine Änderung der Performance-Klasse erfordert daher ein kontrolliertes Ersatzziel:

Wählen Sie die neue Klasse anhand beobachteter IOPS, Durchsatz-, Latenz- und I/O-Wait-Werte.
Prüfen Sie die Bereitschaft für Backup und Datenbank-Rollback.
Stellen Sie Ersatz-VM und Boot Volume mit der gewählten Klasse über IaC bereit.
Wenden Sie die Ansible-Konfiguration erneut an und stellen oder migrieren Sie die Workload-Daten wieder her.
Validieren Sie vor der Umschaltung Applikationsverhalten, Datenintegrität, Storage-Latenz, Backup-Abdeckung und Kosten.

Verwenden Sie ein separates Data Volume, wenn Storage-Kapazität oder -Performance unabhängig vom VM-Lifecycle weiterentwickelt werden müssen. Erstellen Sie für eine andere Performance-Klasse ein neues Volume im erforderlichen Verfügbarkeitsmodell mit ausreichender Kapazität, stoppen Sie Schreibzugriffe, migrieren und verifizieren Sie die Daten, wechseln Sie Attachment oder Mount und bewahren Sie das Quell-Volume auf, bis Abnahme- und Rollback-Gates passiert sind.

Behandeln Sie Storage-Prüfungen als Teil derselben Optimize-Schleife und validieren Sie nach jeder Änderung erneut Latenz, Fehlerverhalten, Recovery und Kostenwirkung.

SAFE

Storage-Pfad entscheiden

Migration migrate optimize rehost observability rightsizing spring-boot

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

STACKIT

Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC.

Code & Registry github.com STACKIT CMF Rehost Spring Boot Repository Arbeiten Sie mit derselben Terraform- und Ansible-Referenzimplementierung weiter, die in den vorherigen Rehost-Migrationsschritten verwendet wurde. Repository öffnen Rehost-Implementierungs-Asset

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Dieselbe Referenzimplementierung fortsetzen

Dieses Asset führt dieselbe Spring-Boot- und PostgreSQL-Referenzimplementierung fort, die für Provisioning, Migration, Cutover und Stabilisierung verwendet wurde. Es führt kein weiteres Beispiel oder Repository ein. Die vorhandenen Terraform-Variablen, Ansible-Konfiguration, Observability-Instanz und Validierungsworkflows bleiben die technische Baseline für Optimize.

Die Optimize-Erweiterung beantwortet eine praktische Frage: Wie lassen sich Über- oder Unterprovisionierung erkennen und VM- oder Storage-Kapazität anschließend über einen kontrollierten IaC-Workflow ändern?

Observability-Setup für die Optimierung

Nutze den managed STACKIT Observability -Stack als Datenquelle.

Prometheus: Metrik-Erfassung
Thanos: Langfristige Aufbewahrung von Metriken
Grafana Loki: Log-Analyse
Grafana Tempo: Distributed Traces
Grafana: Dashboards und Visualisierung

Architektur-Referenzen:

Observability-Entscheidungsdashboard

Nutze das Dashboard, um Infrastruktur-Auslastung, Anwendungszustand, Request-Verhalten und Alert-Historie gemeinsam zu bewerten, bevor die VM-Kapazität geändert wird.

Signale und Schwellwerte für Rightsizing

Definiere technische Schwellwerte, bevor du Kapazität änderst.

Kandidat für Downsize: CPU p95 unter 30% und Memory p95 unter 50% für mindestens 14 Tage.
Kandidat für Scale-up: CPU p95 über 75% oder Memory p95 über 80% während Business-Lastfenstern für mindestens drei Tage in Folge.
Stabilitäts-Guardrail: Keine offenen kritischen Alerts und keine Regression in der Error-Rate-SLO.

Halte Schwellwerte workload-spezifisch und validiere sie gegen reale Traffic-Muster.

Datenbank Sicht für Optimize Entscheidungen

Für stateful Rehost-Workloads sollten Signale aus der Datenbank im selben Dashboard-Zyklus bewertet werden.

Verbindungen: Trend aktiver Verbindungen und Verhalten bei Lastspitzen.
Datenbank Größe: Entwicklung der Datenbankgröße über die Zeit.
Transaktionen: Commit-/Rollback-Trends zur Stabilitätsbewertung.

Nutze diese Signale gemeinsam mit VM-Metriken, damit Optimize-Entscheidungen nicht nur auf CPU oder Memory basieren.

PostgreSQL Flex im späteren Optimize-Pfad

Wenn der Rehost-Workload den Datenbank-Layer später auf PostgreSQL Flex umstellt, sollte DB-Rightsizing in denselben Optimize-Loop aufgenommen werden.

Ziel-Instanz planen: PostgreSQL-Flex-Instanz planen
Flavor und Performance-Klasse abstimmen: Flavors und Performance-Klassen von PostgreSQL Flex
Integriertes Dashboard für schnelle Prüfung: Dashboard-Metriken
Observability-Metriken für Analyse im Detail: Observability-Metriken

Rightsizing-Workflow

Baseline-Metriken und Traces für einen repräsentativen Zeitraum erfassen.
Optimize-Kandidat mit Dashboards und Alert-Historie bestätigen.
Kapazitätsänderung und Rollback-Checkpoint planen.
VM-Größe per Terraform/OpenTofu anpassen.
Latenz, Error-Rates, Durchsatz und Kosten erneut validieren.
Behalten oder zurückrollen anhand objektiver Kriterien.

Praktisches Beispiel

Beispiel A: Downsize nach dauerhaft niedriger Auslastung

Passe die VM-Größe in env.tfvars an:

machine_type = "g3i.2"

Apply und Plan-Ausgabe prüfen:

terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars

Danach validieren:

Service-Health (systemctl status, synthetische Checks)
p95-Latenz und Error-Rate-Trend
Kosten-Differenz im Reporting-Zeitraum

Beispiel B: Scale-up bei dauerhaft hoher Last

Passe die VM-Größe in env.tfvars an:

machine_type = "g3i.4"

Apply durchführen und mit denselben Post-Change-Checks validieren.

Rollback-Muster

Wenn sich SLOs nach dem Rightsizing verschlechtern, rolle zurück, indem du den vorherigen machine_type wiederherstellst und IaC erneut ausführst. Behandle Rollback als regulären Runbook-Schritt und nicht nur als Notfallweg.

Hinweise

Abhängig von Plattform-Constraints und Machine Type kann ein Resize einen Neustart oder Ersatz der VM auslösen. Prüfe das Verhalten vorab in terraform plan.

Storage als Optimierungsaspekt

In Rehost-Szenarien sind CPU und Memory nur eine Seite des Rightsizing. Auch Storage-Performance kann zum Engpass werden.

Wann Storage prüfen: erhöhte I/O-Wait-Werte, instabile Latenz bei schreibintensiver Last oder Throughput-Sättigung trotz freier CPU.
Was auswählen: Storage-Service-Plan und Performance-Klasse passend zum beobachteten IOPS- und Durchsatzprofil.
Guidance: Block Storage Service Plans

Performance-Klasse vor dem Provisioning auswählen

Eine Block-Storage-Performance-Klasse definiert die maximalen IOPS und den maximalen Durchsatz für das gesamte Volume. Zugriffe von Anwendung, Datenbank, Betriebssystem und Backup teilen dieses Performance-Budget. Wählen Sie die Klasse vor dem Erstellen des Volumes anhand gemessener Lastspitzen, Latenzanforderungen, Backup-Aktivität und expliziter Wachstumsreserve.

Aus der STACKIT-DokuService-Pläne › Derzeit verfügbare Servicepläne (Leistungs-Klassen)Stand der Quelle 20.01.2026 · übernommen 05.10.2026

Die folgende Tabelle listet die derzeit verfügbaren Leistungs-Klassen für die Region EU01 auf:

Seitlich wischen, um die ganze Tabelle zu sehen

Leistungs-Klasse	Name	Max. IOPS	Max. Durchsatz (MB/s)
Leistungs-Klasse 0	storage_premium_perf0	120	25
Leistungs-Klasse 1	storage_premium_perf1	500	50
Leistungs-Klasse 2	storage_premium_perf2	1000	100
Leistungs-Klasse 4	storage_premium_perf4	2000	150
Leistungs-Klasse 6	storage_premium_perf6	5000	200
Leistungs-Klasse 8	storage_premium_perf8	10000	250
Leistungs-Klasse 10	storage_premium_perf10	15000	300
Leistungs-Klasse 12	storage_premium_perf12	20000	350
Leistungs-Klasse 13	storage_premium_perf13	20000	700
Leistungs-Klasse 14	storage_premium_perf14	25000	400
Leistungs-Klasse 15	storage_premium_perf15	25000	800
Leistungs-Klasse 16	storage_premium_perf16	30000	450
Leistungs-Klasse 17	storage_premium_perf17	30000	900
Leistungs-Klasse 18	storage_premium_perf18	35000	500
Leistungs-Klasse 19	storage_premium_perf19	35000	1000
Leistungs-Klasse 20	storage_premium_perf20	40000	550
Leistungs-Klasse 21	storage_premium_perf21	40000	1100

IOPS – Input/Output Operations per second (Ein-/Ausgabebefehle pro Sekunde)

Durchsatz – Durchsatz in Megabyte pro Sekunde

Somit lassen sich die verwendeten Klassen anhand der Namensgebung im Detail unterscheiden. Beispiel: „Block Storage Premium – Leistungs-Klasse 2“ entspricht SSD-Festplatten mit max. 1000 IOPS und max. 100 Mbyte/s Durchsatz.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

In der Rehost-Baseline teilen sich Betriebssystem, Spring-Boot-Anwendung und PostgreSQL-Daten das Boot Volume. Eine Änderung der Performance-Klasse erfordert daher ein kontrolliertes Ersatzziel:

Wählen Sie die neue Klasse anhand beobachteter IOPS, Durchsatz-, Latenz- und I/O-Wait-Werte.
Prüfen Sie die Bereitschaft für Backup und Datenbank-Rollback.
Stellen Sie Ersatz-VM und Boot Volume mit der gewählten Klasse über IaC bereit.
Wenden Sie die Ansible-Konfiguration erneut an und stellen oder migrieren Sie die Workload-Daten wieder her.
Validieren Sie vor der Umschaltung Applikationsverhalten, Datenintegrität, Storage-Latenz, Backup-Abdeckung und Kosten.

Verwenden Sie ein separates Data Volume, wenn Storage-Kapazität oder -Performance unabhängig vom VM-Lifecycle weiterentwickelt werden müssen. Erstellen Sie für eine andere Performance-Klasse ein neues Volume im erforderlichen Verfügbarkeitsmodell mit ausreichender Kapazität, stoppen Sie Schreibzugriffe, migrieren und verifizieren Sie die Daten, wechseln Sie Attachment oder Mount und bewahren Sie das Quell-Volume auf, bis Abnahme- und Rollback-Gates passiert sind.