Rehost to STACKIT: Überblick zu Spring Boot und PostgreSQL

Migration assess discovery design-and-mobilize design +5

Partner-Software-Asset für KI-gestützte STACKIT-Migrationsbewertung, R-Strategie-Auswahl, Zielarchitektur, Business Case und evidenzbasierte Migrationsplanung.

CloudMent AI-Powered Cloud Advisor

Migration

Software

Rapid-Discovery-Prozess auf einen Blick

Das folgende Diagramm zeigt den Kern von Rapid Discovery: Rohdaten aus Quellsystemen werden durch Tooling in eine entscheidungsreife Baseline überführt, die frühe Preisindikationen und erste Sizing-Annahmen ermöglicht.

Seitlich wischen, um das ganze Diagramm zu sehen

Methodik in der Praxis

Eine belastbare Rapid Discovery folgt typischerweise einem klaren Ablauf:

Datensammlung aus vorhandenen Quellen (CMDB, Hypervisor-Exporte, Cloud-Inventare, Monitoring, Storage-Reports, Datenbanklisten).
Standardisierung und Konsolidierung der Daten in ein einheitliches Schema.
Kategorisierung nach Workload-Typen und technischen Merkmalen.
Aggregation auf Management-Ebene für schnelle Entscheidungsfindung.
Erste Plausibilisierung mit Fachverantwortlichen.

Ziel ist kein perfektes Zielbild, sondern ein verlässlicher Startpunkt mit ausreichender Genauigkeit für frühe Entscheidungen.

Datenqualität und Annahmen

Die Aussagekraft der Ergebnisse hängt stark von der Datenqualität ab. Typische Herausforderungen sind Dubletten, veraltete Einträge, inkonsistente Benennungen und fehlende Leistungsdaten.

Empfehlung für diese Phase:

Annahmen dokumentieren: Wachstumsraten, Konsolidierungsfaktoren und Reserven transparent halten.
Unklare Datensätze markieren: Unsichere Datensätze kennzeichnen statt früh zu verwerfen.
Konfidenzniveau vergeben: Ergebnisse als hoch, mittel oder niedrig einstufen.

So bleibt die Kostenindikation nachvollziehbar und später in der Discovery-Phase gezielt verfeinerbar.

Verbindung zu Preisindikation und TCO

Rapid Discovery liefert die Mengengerüste für erste Kostenmodelle. Dafür werden die erfassten Bestände in STACKIT-nahe Verbrauchseinheiten überführt, zum Beispiel:

Compute-Sizing: vCPU und RAM als Grundlage nutzen.
Storage-Klassen: Storage-Kapazität und I/O-Profile verwenden.
Managed Services: Datenbanktyp und Größenklassen zuordnen.
Plattformkosten: Cluster- und Node-Anzahlen einbeziehen.

In Kombination mit Betriebsannahmen (Betriebszeiten, Verfügbarkeit, Wachstumspfad) entsteht daraus eine belastbare Preisindikation und ein erster TCO-Korridor.

Typische Ergebnisse

Am Ende der Rapid-Discovery-Phase sollten mindestens folgende Ergebnisse vorliegen:

Konsolidierte Asset-Baseline

Mengen je Technologiebereich liegen konsolidiert vor.

Sinnvolle Segmentierung

Assets sind nach Kritikalität, Umgebung und Modernisierungsbedarf segmentiert.

Nachvollziehbare Annahmen

Annahmen und erkannte Datenlücken sind transparent dokumentiert.

Erste Kostenindikation

Eine erste Kostenbandbreite mit den wichtigsten Treibern liegt vor.

Priorisierte Kandidaten

Eine priorisierte Liste für die vertiefende Discovery-Phase ist verfügbar.

Diese Ergebnisse bilden die Arbeitsgrundlage für Architektur, Planung und Governance der nächsten Assess-Schritte.

Risiken und Gegenmaßnahmen

Häufige Risiken in Rapid Discovery sind zu grobe Kategorisierung, unvollständige Quellsysteme oder eine Überschätzung der Datenreife.

Bewährte Gegenmaßnahmen:

Datenquellen kombinieren: Mehrere Quellen nutzen statt nur einer Quelle.
Ausreißer prüfen: Sehr große oder sehr alte Systeme systematisch bewerten.
Perspektiven abstimmen: Finanz- und Technikblick gemeinsam ausrichten, um Fehlinterpretationen zu vermeiden.

Damit bleibt die Phase schnell, ohne an Entscheidungsqualität zu verlieren.

Übergang in die Discovery-Phase

Der Übergang ist erreicht, wenn ein belastbarer Überblick über Mengen, Technologietypen und Kostenhebel vorliegt und die offenen Punkte klar benannt sind.

In der Discovery-Phase werden diese offenen Punkte gezielt geschlossen, unter anderem durch Interviews mit Application Ownern, vertiefende Assessments und die Analyse von Abhängigkeiten, Compliance- und Betriebsanforderungen.

STEP

Discovery

Kombinieren Sie Nachweise der Application Owner mit technischen Messungen zu Abhängigkeiten, Java- und PostgreSQL-Versionen, Service-Verhalten, Datenmenge und Änderungsrate, Betriebsbedingungen, Recovery-Zielen und repräsentativer Ressourcennutzung. Bestätigen Sie Kompatibilität, Migrationsbedingungen und Kapazitäts-Baseline vor dem Design.

In 4 Trails

Discovery-Analyse aus technischen Nachweisen und Erkenntnissen der Application Owner

Überblick: Discovery

Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize. Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe, um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.

Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft, bevor Zielbild und Migrationsplan im Detail festgelegt werden.

Zentrale Ziele

Vollständige Basis

Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.

Transparente Abhängigkeiten

Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu vermeiden.

Business-Abgleich

Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.

Planungsreife

Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.

Was Discovery typischerweise erfasst

Inventarisierung

Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und Anwendungen.

Abhängigkeitsanalyse

Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.

Ressourcennutzung

Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.

Betriebskontext

Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.

Input der Application Owner

Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von Datenlücken.

Typisches Vorgehen

In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt. Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln, zu normalisieren und in einer zentralen Sammlung zu konsolidieren.

Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt, um technische Befunde um Business und Betrieb zu ergänzen.

Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert Stakeholder-Validierung direkt im Prozess.

Zwei Evidence-Streams: technisch vs. human-driven

Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:

Technisch ermittelte Evidenz: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
Application-Owner-Anreicherung (human-driven): Validierte Angaben zu Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher Realität aus Interviews und Fragebögen.

Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.

Discovery-Prozess auf einen Blick

Die folgende Darstellung zeigt, wie Discovery technische und menschliche Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.

Seitlich wischen, um das ganze Diagramm zu sehen

Typische Analyse-Muster im Discovery-Tooling

Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:

Daten normalisieren: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
Abhängigkeiten abbilden: Kommunikation, Datenaustausch und Kopplungen erkennen.
Kritikalitäts- und Risiko-Bewertung: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
Analyse der Nutzung: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
Segmentierung: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
Wellen-Simulation: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
Gap- und Annahmen-Tracking: Offene Punkte transparent mit einer Einschätzung führen.

Diese Analysen bilden die technische Grundlage. Der human-driven Stream validiert, priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.

KI-gestützte Discovery-Assets

KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.

Asset-Titel

Framework

Asset-Typ

Software

CloudMent AI-Powered Cloud Advisor

CloudMent

Partner-Software-Asset für KI-gestützte STACKIT-Migrationsbewertung, R-Strategie-Auswahl, Zielarchitektur, Business Case und evidenzbasierte Migrationsplanung.

CloudMent AI-Powered Cloud Advisor

Migration

Software

Methodik in der Praxis

Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.

Warum Discovery kritisch ist

Risiko der Migration reduzieren: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
Planung der Wellen verbessern: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
Falsche Dimensionierung vermeiden: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
Governance absichern: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
Stakeholder-Buy-in stärken: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.

Relevanz für nachgelagerte Module

Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:

Design

Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger Zielarchitekturen.

Security und Compliance

Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.

Landing Zone

Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.

Migrationsplan

Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.

Operating Model und Business Case

Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.

Ergebnisse aus Discovery

Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:

Konsolidierte Applikations-Basis: Inventar nach Domäne, Umgebung und Kritikalität.
Abhängigkeitskarte: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
Profil der Nutzung: Belastbare Daten zur Auslastung und Sizing-Annahmen.
Constraint-Register: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
Migrationsreife-Sicht: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.

Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design und einen realistischen Migrationsplan.

LIFT

Rehost-Strategie

Bestätigen Sie anhand der Discovery-Nachweise, dass das Beibehalten von Spring-Boot-JAR, systemd-Service-Modell und PostgreSQL-Engine auf einer VM die Migrationsziele erfüllt; Kubernetes, Cloud Foundry oder PostgreSQL Flex wären stattdessen Replatform. Leiten Sie daraus die Delivery-Reihenfolge ab: Landing Zone, Terraform-Infrastruktur, Ansible-Konfiguration, separate PostgreSQL-Migration und geprobtes Runbook.

In 2 Trails

R-Strategie-Methode mit Rehost als Lift-and-Shift-Pfad auf Anwendungsebene

Überblick: Rehost

Rehost (lift-and-shift) migriert Workloads mit möglichst geringer Anwendungsänderung. Die Strategie reduziert Übergangsrisiken und beschleunigt den Umsetzungsdurchsatz.

Konkret ist Rehost anwendungs- und wellenorientiert: Für jeden Workload werden Zielabbildung, Cutover-Pfad und Runbook-Paket für eine wiederholbare Factory-Ausführung festgelegt.

Rehost vs. Relocate in STACKIT

Relocate und Rehost werden oft gleich verwendet, sind in diesem Framework jedoch bewusst getrennt.

Rehost in STACKIT: Anwendungsbezogener Lift-and-Shift mit klarer Zielabbildung, Cutover-/Rollback-Logik und standardisierten Runbooks.
Relocate in STACKIT: Überführung bestehender Virtualisierungs-Muster mit minimaler Umformung des bestehenden Laufzeitverhaltens.
Wann Rehost bevorzugt wird: Wenn Wellen über viele Anwendungen mit einheitlicher Runbook-Qualität und stabiler Ausführung geplant sind.
Wann Relocate bevorzugt wird: Wenn schnelle Estate-Überführung Priorität hat und Modernisierung bewusst später erfolgt.

Wann Rehost sinnvoll ist

Strenger Zeitrahmen bei begrenzter Engineering-Kapazität.
Legacy-Workloads, die aktuell schwer zu refactoren sind.
Priorität auf Stabilität bei möglichst unverändertem Fachverhalten.
Factory-Skalierung mit wiederholbaren Migrationsabläufen über viele Systeme.

Design-Aspekte im STACKIT-Kontext

Infrastruktur-Abbildung

Zielprofile für Compute, Storage und Netzwerk mit Kompatibilitätsprüfung definieren.

Daten- und Cutover-Pfad

Transferfenster, Konsistenzchecks und Rollback-Trigger entwerfen.

Stateful-Workload-Handling

Applikations-Deployment und Datenbankmigration als getrennte, aber abgestimmte Streams sequenzieren.

Security und Compliance

Identitätskontrollen, Verschlüsselungsanforderungen und Nachweis-Checkpoints abbilden.

Operatives Handover

Runbooks für Day-1-Betrieb und Incident-Ablaufe nach der Migration sicherstellen.

Empfohlener Design-Ablauf

Laufzeitabhängigkeiten und nicht-funktionale Anforderungen baseline.
Zielabbildung und Migrationssequenz definieren.
Datenumzug und Cutover-Orchestrierung entwerfen.
Runbook-Qualität mit Dry-Run-Checkpoints validieren.
Produktive Migration mit Release- und Business-Sign-off freigeben.

Datenmigrationspfad bei Rehost

In Rehost-Szenarien hängt der Datenmigrationspfad davon ab, ob der Workload zustandslos (stateless) oder zustandsbehaftet (stateful) ist:

Stateless-Workloads: Fokus auf Anwendungs-Deployment und Konfiguration.
Stateful-Workloads: Erfordern eine koordinierte Datenverschiebungs-Strategie parallel zur Anwendungsmigration.

Für zustandsbehaftete Migrationswellen empfiehlt sich eine Trennung in zwei Streams:

Infrastruktur- und Anwendungs-Stream: Zielumgebung bereitstellen, Anwendung bereitstellen und Zieldatenspeicher vorbereiten.
Daten-Stream: Quelldaten exportieren, zum Ziel übertragen, wiederherstellen und validieren.

Empfohlene Datensequenz

Quelldaten mit plattformnativen oder werkspezifischen Methoden exportieren.
Daten in die Zielumgebung oder einen Zwischenspeicher übertragen.
Zielumgebung für den Import der migrierten Daten konfigurieren.
Wiederherstellungsprozess ausführen und Datenintegrität verifizieren.
Anwendungskonnektivität und funktionales Verhalten vor der endgültigen Umschaltung validieren.

Erforderliche Ergebnisse

Gemeinsame Ergebnisse für alle Migrationspfade

Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
Übergabepaket für Migration Factory Setup und Wellenplanung.

Rehost-spezifische Ergebnisse

Rehost-Entscheidungsbegründung und Randbedingungen.
Zielabbildung der Laufzeit.
Datenumzugs- und Cutover-Plan.
Runbook mit Validierungs- und Rollback-Checkpoints.
Stabilisierungsliste nach der Welle.

Diagramm-Schrittreferenz

Define Landing Zone

Landing-Zone-Anforderungen und Controls als Startpunkt der Rehost-Ausführung festlegen. Netzwerk-, Identitäts-, Backup- und Monitoring-Voraussetzungen vor der Abfolge der Migration verbindlich festlegen, damit Rehost-Wellen mit planbarer Betriebsqualität umgesetzt werden.

Use migration tools

Automatisierten Rehost-Pfad für wiederholbaren Wellen-Durchsatz definieren. Im automatisierten Rehost-Pfad werden Infrastruktur und Anwendung als Code bereitgestellt, damit Wellen reproduzierbar und auditierbar umgesetzt werden können.

VM-Ziel über IaC bereitstellen: Netzwerk, Security-Gruppen, Compute-Instanzen und Basis-Storage mit Terraform oder OpenTofu aufbauen.
Anwendung automatisiert installieren und konfigurieren: Ansible-Playbooks für die Installation von Paketen, Service-Setup und Basiskonfiguration verwenden.
Parameter der Zielumgebung kontrolliert anwenden: Variablen im Ziel, Secret-Referenzen und Endpoint-Mappings in einem gesteuerten automatisierten Lauf einspielen.
Automatisierte Validierungs- und Cutover-Gates ausführen: Health-Checks, Migrations-Pre-Checks, Rollback-Checkpoints und Release-Freigaben vor Live-Switch durchführen.
Runbook Blueprint
Migrationsplan

Asset-Titel

Framework

Asset-Typ

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

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

STEP

Mit Terraform und Ansible automatisieren

Trennen Sie Infrastruktur-Lifecycle und Zielkonfiguration: Terraform oder OpenTofu erstellt und synchronisiert STACKIT Ressourcen, während Ansible das erreichbare Betriebssystem, Middleware, Anwendung und Validierungskontrollen konfiguriert.

In 3 Trails

Zielbild

Automatisierung stellt sicher, dass Landing-Zone-Funktionen reproduzierbar, versioniert und testbar bereitgestellt werden.

Für Migrations-Landing-Zones ist Automatisierung das Delivery-Rückgrat, das Plattform-APIs, IaC-Werkzeuge, Entwickler-Workflows und Release-Kontrollen in ein verlässliches Betriebsmodell überführt.

Kernbausteine der Automatisierung

STACKIT API: Nutzen Sie die API als grundlegende Steuerungsschnittstelle für Plattformautomatisierung und Integrationsmuster. Dokumentation
Terraform Provider: Nutzen Sie den offiziellen Provider für deklarative Infrastruktur-Bereitstellung und Lifecycle-Steuerung. Dokumentation
OpenTofu Provider: Nutzen Sie OpenTofu mit dem STACKIT Provider als offene IaC-Option mit vergleichbaren deklarativen Workflows. Dokumentation
Pulumi: Nutzen Sie Pulumi, wenn Teams für Infrastruktur-Automatisierung allgemeine Programmiersprachen bevorzugen. Dokumentation
Ansible: Nutzen Sie Ansible primär für Post-Provisioning-Konfiguration und Betriebsaufgaben. In einem kombinierten Modell stellen Terraform/OpenTofu die Infrastruktur bereit, während Ansible OS- und Middleware-Konfiguration übernimmt.
STACKIT CLI: Standardisieren Sie CLI-basierte Operationen für Skripting, Fehleranalyse und wiederholbare Betriebsaufgaben. Dokumentation
SDKs (Go, Python, Java): Nutzen Sie SDKs für kundenspezifische Automatisierung und Service-Integrationen, wenn IaC-Abstraktionen nicht ausreichen. Go SDK , Python SDK , Java SDK .
STACKIT Git: Nutzen Sie Git als Source of Truth für IaC-Module, Policies und Delivery-Workflows. Dokumentation
CI/CD Pipeline: Nutzen Sie Pipelines für Validierung, Policy-Prüfungen, kontrollierte Promotion und auditierbare Releases. Dokumentation
Container Registry: Nutzen Sie eine zentrale Registry für versionierte Build-Artefakte und konsistente Deployments über Umgebungen hinweg. Dokumentation

Wie die Bausteine zusammenspielen

Steuerungsschicht: STACKIT API, CLI und SDKs liefern direkte und programmierbare Steuerungsschnittstellen.
Provisioning-Schicht: Terraform/OpenTofu und Pulumi definieren und synchronisieren den gewünschten Infrastrukturzustand.
Konfigurationsschicht: Ansible setzt Host- und Middleware-Konfiguration nach dem Infrastruktur-Provisioning um.
Delivery-Schicht: Git und CI/CD Pipelines erzwingen Qualitäts-Gates, Policy-Prüfungen und kontrollierten Rollout über Umgebungen.
Artefakt-Schicht: Die Container Registry liefert unveränderliche und versionierte Artefakte für vorhersehbare Deployments.

Delivery-Flow mit Terraform/OpenTofu und Ansible

Terraform oder OpenTofu und Ansible lösen unterschiedliche Aufgaben innerhalb eines Delivery-Flows. Halten Sie die Grenze explizit, damit Infrastrukturänderungen prüfbar und Host-Konfigurationen wiederholbar bleiben.

Terraform / OpenTofu

Verantwortet den Infrastruktur-Lifecycle: Projekte, Netzwerke, Sicherheitskontrollen, Compute, Storage, Managed Services und die für das Konfigurationsmanagement benötigten Outputs.

Ansible

Verantwortet die Konfiguration im erreichbaren Ziel: Betriebssystempakete, Middleware, Applikationsartefakte, Service Units und die Validierung auf Workload-Ebene.

Versionieren Sie Infrastruktur-Inputs, Konfiguration und Referenzen auf Applikationsartefakte in Git.
Validieren und prüfen Sie den Terraform/OpenTofu-Plan einschließlich Ersetzungen und Security-Auswirkungen.
Wenden Sie den freigegebenen Plan an und übergeben Sie nur das von Ansible benötigte Zielinventar und die erforderlichen Outputs.
Führen Sie Ansible idempotent aus, um Betriebssystem, Middleware, Workload und Telemetrie zu konfigurieren.
Validieren Sie Infrastrukturzustand, Service Health und betriebliche Kontrollen und bewahren Sie die Nachweise auf.
Promoten Sie denselben versionierten Workflow durch die Umgebungen, statt manuelle Einrichtungsschritte zu wiederholen.

Verwischen Sie die Zuständigkeit beider Ebenen nicht durch Provisioner oder Ad-hoc-Skripte. Ansible aus Terraform anzustoßen kann eine praktische Brücke sein, aber jedes Werkzeug muss eigenständig verständlich, testbar und wiederholbar bleiben.

Empfohlenes Betriebsmodell

Empfehlung 1: Nutzen Sie Git plus CI/CD als Standard-Steuerungspfad und vermeiden Sie direkte manuelle Änderungen in produktiven Scopes.
Empfehlung 2: Wählen Sie je Plattformdomäne ein primäres IaC-Tool (Terraform oder OpenTofu), um Fragmentierung zu reduzieren.
Empfehlung 3: Nutzen Sie Ansible für Konfigurationsmanagement, nicht als Ersatz für deklaratives Infrastruktur-Provisioning.
Empfehlung 4: Nutzen Sie SDKs für domänenspezifische Automatisierung, wenn Provider-Ressourcen das gewünschte Verhalten nicht abdecken.
Empfehlung 5: Versionieren und promoten Sie Container-Artefakte über klare Umgebungsstufen mit rollbackfähigen Tags.

Wichtige Entscheidungen

Automatisierungs-Schnittstellenstrategie: Definieren Sie, wo API, CLI, SDK und IaC-Werkzeuge als Primärschnittstellen eingesetzt werden.
IaC-Tool-Strategie: Entscheiden Sie Terraform versus OpenTofu versus Pulumi anhand von Skills, Governance und Ecosystem-Fit.
Modul- und Repository-Strategie: Definieren Sie wiederverwendbare Modulgrenzen, Versionierung und Ownership.
Pipeline-Control-Modell: Implementieren Sie Validierung, Policy-Prüfungen, Freigaben und Promotion-Gates.
Artefakt- und Release-Strategie: Definieren Sie Registry-Nutzung, Image-Versionierung und Rollback-Standards.

Typische Ergebnisse

Wiederverwendbare Automatisierungs-Baseline: IaC-Module, Templates und Konfigurations-Playbooks mit Ownership-Modell.
Delivery-Blueprint: CI/CD-Flow mit Qualitäts-Gates, Policy-Prüfungen und gestufter Promotion.
Integrations-Toolkit: Standardisierte Nutzung von CLI- und SDK-Automatisierung für Betrieb und produktspezifische Workflows.
Release-Baseline: Versionierter Artefakt-Lifecycle in der Container Registry mit rollbackfähigen Praktiken.

Typische Anti-Patterns

Zu viele Automatisierungs-Paradigmen: Parallele Tool-Stacks ohne klare Ownership oder Governance-Modell.
Provisioning und Konfiguration ad hoc vermischt: Keine klare Trennung zwischen IaC-Provisioning und Ansible-Konfiguration.
Keine Artefakt-Disziplin: Veränderliche Container-Tags und unklare Release-Nachverfolgbarkeit.
CLI-Skripte ohne Git- und Pipeline-Kontrollen: Betriebsautomatisierung ist nicht verlässlich auditierbar oder reproduzierbar.

OPS

Zielarchitektur

Blueprint

Spring Boot und PostgreSQL auf einer VM mit Observability und Backup

STACKIT

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

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

Owner

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.

AUTO

Datenbankmigration

Trennen Sie nach der Definition von Infrastruktur und Laufzeitpfad die Vorbereitung der Anwendung von PostgreSQL-Export, Übertragung, Restore und Integritätsvalidierung. Definieren Sie Write Freeze, finalen Dump, Rollback-Deadline und Aufbewahrung der Quelle vor der Ausführung.

In 2 Trails

Kontrollierter PostgreSQL-Rehost-Pfad von Source Freeze und Nachweisen über Probe und transaktionalen Cutover bis zur Abnahme oder zum Rollback

Überblick: Rehost

Rehost (lift-and-shift) migriert Workloads mit möglichst geringer Anwendungsänderung. Die Strategie reduziert Übergangsrisiken und beschleunigt den Umsetzungsdurchsatz.

Konkret ist Rehost anwendungs- und wellenorientiert: Für jeden Workload werden Zielabbildung, Cutover-Pfad und Runbook-Paket für eine wiederholbare Factory-Ausführung festgelegt.

Rehost vs. Relocate in STACKIT

Relocate und Rehost werden oft gleich verwendet, sind in diesem Framework jedoch bewusst getrennt.

Rehost in STACKIT: Anwendungsbezogener Lift-and-Shift mit klarer Zielabbildung, Cutover-/Rollback-Logik und standardisierten Runbooks.
Relocate in STACKIT: Überführung bestehender Virtualisierungs-Muster mit minimaler Umformung des bestehenden Laufzeitverhaltens.
Wann Rehost bevorzugt wird: Wenn Wellen über viele Anwendungen mit einheitlicher Runbook-Qualität und stabiler Ausführung geplant sind.
Wann Relocate bevorzugt wird: Wenn schnelle Estate-Überführung Priorität hat und Modernisierung bewusst später erfolgt.

Wann Rehost sinnvoll ist

Strenger Zeitrahmen bei begrenzter Engineering-Kapazität.
Legacy-Workloads, die aktuell schwer zu refactoren sind.
Priorität auf Stabilität bei möglichst unverändertem Fachverhalten.
Factory-Skalierung mit wiederholbaren Migrationsabläufen über viele Systeme.

Design-Aspekte im STACKIT-Kontext

Infrastruktur-Abbildung

Zielprofile für Compute, Storage und Netzwerk mit Kompatibilitätsprüfung definieren.

Daten- und Cutover-Pfad

Transferfenster, Konsistenzchecks und Rollback-Trigger entwerfen.

Stateful-Workload-Handling

Applikations-Deployment und Datenbankmigration als getrennte, aber abgestimmte Streams sequenzieren.

Security und Compliance

Identitätskontrollen, Verschlüsselungsanforderungen und Nachweis-Checkpoints abbilden.

Operatives Handover

Runbooks für Day-1-Betrieb und Incident-Ablaufe nach der Migration sicherstellen.

Empfohlener Design-Ablauf

Laufzeitabhängigkeiten und nicht-funktionale Anforderungen baseline.
Zielabbildung und Migrationssequenz definieren.
Datenumzug und Cutover-Orchestrierung entwerfen.
Runbook-Qualität mit Dry-Run-Checkpoints validieren.
Produktive Migration mit Release- und Business-Sign-off freigeben.

Datenmigrationspfad bei Rehost

In Rehost-Szenarien hängt der Datenmigrationspfad davon ab, ob der Workload zustandslos (stateless) oder zustandsbehaftet (stateful) ist:

Stateless-Workloads: Fokus auf Anwendungs-Deployment und Konfiguration.
Stateful-Workloads: Erfordern eine koordinierte Datenverschiebungs-Strategie parallel zur Anwendungsmigration.

Für zustandsbehaftete Migrationswellen empfiehlt sich eine Trennung in zwei Streams:

Infrastruktur- und Anwendungs-Stream: Zielumgebung bereitstellen, Anwendung bereitstellen und Zieldatenspeicher vorbereiten.
Daten-Stream: Quelldaten exportieren, zum Ziel übertragen, wiederherstellen und validieren.

Empfohlene Datensequenz

Quelldaten mit plattformnativen oder werkspezifischen Methoden exportieren.
Daten in die Zielumgebung oder einen Zwischenspeicher übertragen.
Zielumgebung für den Import der migrierten Daten konfigurieren.
Wiederherstellungsprozess ausführen und Datenintegrität verifizieren.
Anwendungskonnektivität und funktionales Verhalten vor der endgültigen Umschaltung validieren.

Erforderliche Ergebnisse

Gemeinsame Ergebnisse für alle Migrationspfade

Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
Übergabepaket für Migration Factory Setup und Wellenplanung.

Rehost-spezifische Ergebnisse

Rehost-Entscheidungsbegründung und Randbedingungen.
Zielabbildung der Laufzeit.
Datenumzugs- und Cutover-Plan.
Runbook mit Validierungs- und Rollback-Checkpoints.
Stabilisierungsliste nach der Welle.

Diagramm-Schrittreferenz

Define Landing Zone

Landing-Zone-Anforderungen und Controls als Startpunkt der Rehost-Ausführung festlegen. Netzwerk-, Identitäts-, Backup- und Monitoring-Voraussetzungen vor der Abfolge der Migration verbindlich festlegen, damit Rehost-Wellen mit planbarer Betriebsqualität umgesetzt werden.

Use migration tools

Automatisierten Rehost-Pfad für wiederholbaren Wellen-Durchsatz definieren. Im automatisierten Rehost-Pfad werden Infrastruktur und Anwendung als Code bereitgestellt, damit Wellen reproduzierbar und auditierbar umgesetzt werden können.

VM-Ziel über IaC bereitstellen: Netzwerk, Security-Gruppen, Compute-Instanzen und Basis-Storage mit Terraform oder OpenTofu aufbauen.
Anwendung automatisiert installieren und konfigurieren: Ansible-Playbooks für die Installation von Paketen, Service-Setup und Basiskonfiguration verwenden.
Parameter der Zielumgebung kontrolliert anwenden: Variablen im Ziel, Secret-Referenzen und Endpoint-Mappings in einem gesteuerten automatisierten Lauf einspielen.
Automatisierte Validierungs- und Cutover-Gates ausführen: Health-Checks, Migrations-Pre-Checks, Rollback-Checkpoints und Release-Freigaben vor Live-Switch durchführen.
Runbook Blueprint
Migrationsplan

Asset-Titel

Framework

Asset-Typ

Zur Platform Landing Zone

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

BASE

Landing Zone

Etablieren Sie die gesteuerte Cloud-Basis, bevor das Rehost-Ziel davon abhängt. Verwenden Sie die sechs Kernkomponenten als Readiness-Rahmen: Jede Kontrolle benötigt Ownership, eine freigegebene Implementierung und Nachweise, bevor Terraform das Spring-Boot-Ziel bereitstellt.

In 5 Trails

Sechs Kernkomponenten einer sicheren STACKIT Landing Zone: Governance, Identity, Security, Netzwerk, Kostenkontrolle und Automatisierung

Überblick: Landing Zones

Eine Landing Zone ist die strukturierte Cloud-Grundlage, die festlegt, wie Ihre Organisation auf STACKIT von Anfang an betrieben wird. Sie verbindet Governance, Identität, Security, Netzwerkarchitektur, Kostensteuerung und Automatisierung zu einem belastbaren Rahmen.

Ohne diese Grundlage stocken Migrationswellen typischerweise durch fehlende Freigaben, inkonsistente Kontrollen und wiederkehrende Plattformentscheidungen.

Kernkomponenten

Die folgende Visualisierung zeigt die zentralen Komponenten für eine belastbare Plattform-Basis.

Warum Sie eine Landing Zone brauchen

Kontrolle und Risikoreduktion: Security- und Compliance-Kontrollen werden konsistent umgesetzt.
Skalierbare Delivery-Basis: Wiederverwendbare Muster beschleunigen mehrere Migrationswellen.
Klare Verantwortlichkeiten: Zuständigkeiten zwischen Plattform-, Security- und Applikationsteams sind klar.
Höhere Umsetzungsgeschwindigkeit: Grundlegende Kontrollen müssen nicht je Applikation neu entworfen werden.

Wann Sie starten sollten

Starten Sie den Landing-Zone-Stream so früh wie möglich parallel zum Discovery.

Zu spät: Produktive Migrationen werden blockiert, weil Pflichtkontrollen noch fehlen.
Zu früh ohne Discovery-Feedback: Relevante Applikationsrandbedingungen fehlen und führen zu Nacharbeit.

Bewährt hat sich ein zweigleisiges Vorgehen: Die Plattform-Basis früh etablieren und Application-Landing-Zone-Templates iterativ mit Discovery-Erkenntnissen verfeinern.

Zwei Ebenen: Platform und Application Landing Zone

Platform Landing Zone

Unternehmensweite Grundlage für Governance, Identität, Security, Netzwerk, Kostensteuerung und Automatisierung.

Application Landing Zone

Workload-spezifische Umsetzungsprofile, abgeleitet aus Plattform-Basis und Discovery-Ergebnissen.

Zur Application Landing Zone

Typische Eingaben aus dem Unternehmen

Für ein belastbares Landing-Zone-Design werden typischerweise benötigt:

Organisations- und Ownership-Modell: Einheiten, Projektgrenzen und Verantwortungsmodell.
Compliance- und Policy-Anforderungen: Regulatorische Pflichten und interne Kontrollvorgaben.
Security-Anforderungen: IAM-Standards, Netzsegmentierung, Verschlüsselung und Logging.
Betriebs- und Supportvorgaben: Incident-Prozesse, Eskalationswege und Übergabemodell.
Erkenntnisse aus dem Applikationsportfolio: Discovery-Resultate zu Abhängigkeiten und Archetypen.

Vorgehensmodell

Unternehmensweite Leitplanken und Kontrollmodell definieren.
Platform Landing Zone als Code aufbauen und validieren.
Application-Landing-Zone-Templates aus Discovery und Migrationsdesign ableiten.
Mit Pilot-Workloads testen und über Migration-Factory-Runbooks skalieren.

STACKIT Beschleuniger und Assets

Um die Umsetzung zu beschleunigen, bietet STACKIT konkrete Best Practices und wiederverwendbare Vorlagen:

Asset-Titel

Framework

Asset-Typ

Blueprint

STACKIT Landing Zone Accelerator

STACKIT

Migration design-and-mobilize landing-zone opentofu terraform +1

Migration design-and-mobilize landing-zone relocate vmware +4

STACKIT Basis-Asset zum Aufbau einer Platform Landing Zone mit wiederverwendbaren OpenTofu/Terraform-Modulen, Enterprise-Standards und zentralem Kubernetes.

STACKIT Landing Zone Accelerator

Migration

Blueprint

VM Application Landing Zone für Relocate

STACKIT

Migration design-and-mobilize landing-zone managed-service opentofu +1

Technisches Blueprint zum Aufbau einer VM Application Landing Zone mit STACKIT Accelerator, manuellen Security Groups und Coriolis- oder Acura-Übergabe.

VM Application Landing Zone für Relocate

Migration

Blueprint

Service

Managed Landing Zone Service

STACKIT

Managed Asset Marketplace In 1 Trail

STACKIT Managed Service für Beratung, Einrichtung und Umsetzung von Landing Zones mit OpenTofu, Terragrunt und Boilerplate-Accelerators für Migration.

Managed Landing Zone Service

Migration

Service

Blueprint

meshStack Self-Service Landing Zone

meshcloud

Migration design-and-mobilize landing-zone dev-platform opentofu

Open Source

Referenzarchitektur, die eine STACKIT Landing Zone um Self-Service mit Governance ergänzt: Applikationsteams bestellen Projekte und geroutete Netzwerke selbst.

meshStack Self-Service Landing Zone

Migration

Blueprint

Software

pfSense-Firewall-Connectivity-Pattern

STACKIT

Migration design-and-mobilize landing-zone network network-area +3

Open Source

Leitfaden für den Einsatz der STACKIT pfSense Firewall als zentraler Kontrollpunkt in Hub-and-Spoke-Network-Area-Architekturen für sichere STACKIT-Migrationen.

pfSense-Firewall-Connectivity-Pattern

Migration

Software

Service

CAF Landing Zones Implementation (PRODYNA)

PRODYNA

Migration design-and-mobilize landing-zone caf managed-service +1

Managed Asset Marketplace In 1 Trail

CAF Landing Zone Foundation Accelerator von PRODYNA: ein CAF-basierter Enterprise-IaC-Blueprint-Hackathon für sichere und skalierbare STACKIT Landing Zones.

CAF Landing Zones Implementation (PRODYNA)

Migration

Service

Basis als Code beschleunigen

Nutzen Sie den STACKIT Landing Zone Accelerator, um wiederverwendbare Organisations-Folder, Plattformprojekte, Connectivity, Management Services und die Workload-bereite Application Landing Zone zu erstellen, bevor die Rehost-Automatisierung ihre VM deployt.

Halten Sie die Grenze explizit: Der Accelerator stellt die gesteuerte Umgebung bereit; das Application Team deployt Spring Boot, PostgreSQL, Telemetrie und Backup in die freigegebene Application Landing Zone.

Architektur des Landing Zone Accelerators mit getrennten Verantwortlichkeiten für Plattform, Application Landing Zone und Workload

LIVE

Migration Framework

Beginnen Sie die Ausführung nur mit freigegebenen Designentscheidungen, einer bereiten Application Landing Zone, einer zugewiesenen Welle und einem Factory-fähigen Runbook. Führen Sie Readiness, Migration, Cutover, Validierung, Stabilisierung und Handover als einen kontrollierten Ablauf aus.

In 4 Trails

Überblick: Migrate-Modul

Dieses Modul setzt die eigentliche technische Migration in der Migration Factory um. Zu diesem Zeitpunkt sind Entscheidungen aus Design getroffen, Landing Zones aufgebaut und Wellen geplant.

Der Fokus liegt auf reproduzierbarer Umsetzung für:

Relocate: Verlagerung von Workloads mit minimalen Änderungen an Annahmen zur Plattform.
Rehost: Lift-and-Shift auf STACKIT mit kontrolliertem Cutover und Rollback-Bereitschaft.
Replatform: Gezielte Anpassungen an der Plattform während der Migration ohne vollständiges Redesign.

Abhängigkeiten aus Design and Mobilize

Migrate startet erst, wenn aus der vorherigen Phase umsetzbare Ergebnisse vorliegen:

Design je Anwendung: Zielbild, Schnittstellen, Daten und nicht-funktionale Anforderungen sind festgelegt.
Zuordnung zur Wellenplanung: Jede Anwendung ist einer freigegebenen Welle mit Zeitfenster und Abhängigkeiten zugeordnet.
Runbook je Pfad der Migration: Für Pfad und Typ von Workload liegt ein validiertes Runbook vor, inklusive Go/No-Go-, Cutover- und Rollback-Kriterien.
Zuordnung zur Application Landing Zone: Anwendungen sind der passenden Ziel-Landing-Zone und Ownership zugeordnet.
Entscheidungswege und Kommunikation: Entscheidungswege, Eskalationsprozess und Kommunikation mit dem Application Owner sind festgelegt, inklusive der Frage, ob der Cutover gemeinsam durchgeführt werden muss.

Verweise auf Module:

End-to-End-Ablauf in der Factory

Wellenscope, Cutover-Fenster, Rollback-Kriterien und Runbook-Verantwortung final bestätigen.
Wellen-Baseline einfrieren (Versionen, Abhängigkeiten, Datenscope, Schnittstellenverträge).
Technische Readiness-Prüfungen in Quelle und Ziel durchführen.
Runbook-Schritte je Workload-Archetyp und R-Strategie-Pfad ausführen.
Cutover durchführen und Traffic gemäß Wellenplan auf STACKIT umschalten.
Technische, funktionale und operative Akzeptanzkriterien validieren.
Stabilisierungsmaßnahmen in kurzen Feedback-Schleifen umsetzen.
Stabilisierte Workloads an Optimize und Operate übergeben.

Ablauf je R-Pfad

Relocate-Ablauf

Platzierung im Ziel auf STACKIT mit äquivalenten Annahmen zur Topologie herstellen.
Daten und Zustände mit Konsistenzprüfungen migrieren.
Traffic mit Rollback-Leitplanken umschalten.
Geschäftskontinuität und operative Telemetrie verifizieren.

Rehost-Ablauf

Applikationen und Daten weitgehend unverändert übertragen.
Infrastruktur-Bindings und Konnektivität auf STACKIT neu zuordnen.
Kontrollierten Cutover mit Smoke-Tests durchführen.
Phase zur Stabilisierung und Performance-Baseline abschließen.

Replatform-Ablauf

Ausgewählte Managed Services und Plattformfunktionen in den Pfad der Migration integrieren.
Konfiguration, Deployment-Artefakte und Kontrollen im Betrieb anpassen.
Cutover mit Kompatibilitäts- und Datenintegritätsprüfungen durchführen.
SLO-Verhalten und Betriebsreife der Zielumgebung nachweisen.

Zentrale Artefakte pro Welle

Runbook-Nachweise

Vollständige Runbook-Protokolle, Entscheidungsnachweise und Rollback-Checkpoints pro Workload.

Cutover-Report

Zeitlich nachvollziehbares Ergebnis mit Abnahme, Defekten und eingeleiteten Maßnahmen.

Operative Baseline

Initiales Monitoring, Alerting, Ownership und Incident-Prozesse in der Zielumgebung.

Optimize-Backlog

Priorisierte Maßnahmen für Rightsizing, Performance-Tuning und Kostenoptimierung.

Abgrenzung zu Optimize, Repurchase und Refactor

Optimize startet direkt nach stabilem Cutover und nutzt Daten aus dem Betrieb für Tuning und Kostensteuerung: Optimize.
Repurchase folgt einer anderen SaaS-Logik und läuft bewusst außerhalb des klassischen Modells mit Wellen: Repurchase.
Refactor wird als eigener Pfad für Transformation geführt: Refactor.

Unterstützung direkt nach dem Cutover kann sich zeitlich mit Optimize überschneiden, wird aber inhaltlich in der Run-Phase behandelt.

SAFE

Freigabepunkte der Migration

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

Spring Boot mit Terraform und Ansible rehosten

STACKIT

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

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.

Owner

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

Technische Umsetzung

STACKIT Neu

Rehost to STACKIT: Spring Boot mit Terraform und Ansible

Migrieren Sie Spring Boot und PostgreSQL auf eine STACKIT-VM mit Terraform und Ansible: Eingaben, Bereitstellung, Probe, Cutover, Abnahme und Betriebsübergabe.

Migration rehost spring-boot postgresql terraform +2

Trail Steps

Rehost-Strategie
Zielarchitektur
Referenzimplementierung
Arbeitsumgebung vorbereiten

+ 16 more steps

GOAL

Abnehmen und an den Betrieb übergeben

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.

Owner

STACKIT

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

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

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.