Spring Boot und PostgreSQL auf einer VM mit Observability und Backup

Ü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

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

1. Datei aus dem Beispiel kopieren: cp env.tfvars.example env.tfvars
2. 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

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

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

4. 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.