---
title: "Spring Boot und PostgreSQL auf einer VM mit Observability und Backup"
description: "Validierte Rehost-Architektur für ein Spring-Boot-JAR und selbstverwaltetes PostgreSQL auf einer STACKIT VM mit eingeschränktem Ingress, Observability und Server Backup."
sidebar:
  badge:
    text: "STACKIT"
    variant: success
scfAsset:
  managed: false
  category: 'blueprint'
  external: false
  tags: ["design-and-mobilize", "design", "target-architecture", "rehost", "spring-boot", "vm", "postgresql", "observability", "backup"]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/architecture-spring-boot-vm-load-balancer-monitoring-backup/"
source_file: "docs/de/migration/assetcontainer/stackit/architecture-spring-boot-vm-load-balancer-monitoring-backup.mdx"
---

## Ü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

```d2
vars: {
  d2-config: {
    pad: 32
  }
}

style.font-size: 22

direction: right

Internet: "Internet" {
  icon: ../../../../../../../public/stackit-icons/networking/ip.svg
}

VMProject: "Application Project" {
  PublicIP: "Public IP"
  VM: "Ubuntu VM" {
    icon: ../../../../../../../public/stackit-icons/computing/virtual-machine.svg
    link: https://docs.stackit.cloud/products/compute-engine/server/
    App: "Spring Boot JAR + systemd"
    DB: "Selbstverwaltetes PostgreSQL"
    Exporter: "Node Exporter"
  }
  Obs: "Observability" {
    icon: ../../../../../../../public/stackit-icons/logging-monitoring/observability.svg
    link: https://docs.stackit.cloud/products/logging-and-monitoring/observability/
  }
  BackupArchive: "Backup Archive" {
    icon: ../../../../../../../public/stackit-icons/computing/archive.svg
    link: https://docs.stackit.cloud/products/compute-engine/server-backup-management/
  }
}

Internet -> VMProject.PublicIP: "eingeschränktes HTTP/SSH"
VMProject.PublicIP -> VMProject.VM.App
VMProject.VM.App -> VMProject.VM.DB: "lokales SQL"
VMProject.Obs -> VMProject.VM.Exporter: "eingeschränkter Scrape"
VMProject.VM -> VMProject.BackupArchive: "Boot-Volume-Backup"
```

## 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

- <LinkChip href="/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/">Runbook Asset: Rehost Spring Boot with Terraform/OpenTofu and Ansible</LinkChip>

## Repository

<LinkCard
  title="STACKIT CMF Rehost Spring Boot repository"
  href="https://github.com/stackitcloud/stackit-cmf-rehost-springboot"
/>

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

```hcl
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`):

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

4. Ausführen:

```bash
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.