Cloud Run und Cloud SQL: eine vollständige Bewertung im Detail

Der Lauf in Zahlen

Am 4. November 2026 von StackToIT offline bewertet, an einer für diese Seite geschriebenen Umgebung. Alle Zahlen stammen aus der Konsolenausgabe des Laufs und aus assessment.json.

Der Lauf endete mit 12 von 12 bestandenen globalen Invarianten, von denen drei für diese Umgebung nichts geprüft haben.

Die Datenbank: Cloud SQL zu PostgreSQL Flex

Links die regionale PostgreSQL-16-Instanz der Eingabe mit privater IP und Point-in-Time-Recovery. Rechts die Blöcke des STACKIT-Terraforms aus dem Lauf; die Prüfkommentare über jedem Block sind hier ausgelassen.

resource "google_sql_database_instance" "orders" {
  name             = "orders-pg"
  region           = "europe-west3"
  database_version = "POSTGRES_16"
  depends_on       = [google_service_networking_connection.sql]

  settings {
    tier              = "db-custom-2-8192"
    availability_type = "REGIONAL"
    disk_size         = 100
    disk_type         = "PD_SSD"

    ip_configuration {
      ipv4_enabled    = false
      private_network = google_compute_network.shop.id
    }

    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
}

resource "google_sql_database" "orders" {
  name     = "orders"
  instance = google_sql_database_instance.orders.name
}

resource "stackit_postgresflex_instance" "orders" {
  project_id = var.project_id
  name       = "orders-pg"
  version    = "16"
  flavor_id  = "2.16-replica"
  storage = {
    class = var.postgresflex_storage_class
    size  = 100
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.orders_allowed_cidrs
  }
  retention_days = 32
}

resource "stackit_postgresflex_database" "orders_orders" {
  project_id  = var.project_id
  instance_id = stackit_postgresflex_instance.orders.instance_id
  name        = "orders"
  owner       = var.orders_orders_owner
}

• Version, Speicher und Datenbank bleiben

  PostgreSQL 16, 100 GB und der Datenbankname stehen im Entwurf. Aus dem regionalen Tier db-custom-2-8192 wird das Flavor 2.16-replica, laut Kommentar des Laufs 2 vCPU und 16 GiB: das kleinste Replica-Flavor in eu01, das 2 vCPU und 8 GB abdeckt.

• Private IP hat kein Gegenstück

  Die Instanz ist unter dem Endpunkt erreichbar, den STACKIT vergibt, begrenzt durch eine ACL. Die Liste erlaubter Adressen ist eine Variable, die Sie füllen.

• Point-in-Time-Recovery ist keine Einstellung

  Die STACKIT-Anleitung zu Backup und Clone bestätigt das: Ein Backup wird, auch auf einen bestimmten Zeitpunkt, in eine neue Instanz im selben Projekt wiederhergestellt; eine Wiederherstellung an Ort und Stelle gibt es nicht. Die Eingabe legt keine Aufbewahrung fest, also behält Cloud SQL seinen Standardwert von sieben automatischen Backups; der Lauf hält das als 7 Tage fest, und der Entwurf setzt retention_days = 32. Den täglichen Backup-Zeitpunkt 02:00 nennt der Lauf einen Standardwert, den Sie bestätigen sollten.

Der Dienst: Cloud Run zu einem Workload auf SKE

Links der Cloud-Run-Dienst mit Secret-Referenz, Bucket-Variable und VPC-Zugriff. Rechts der Cluster, den der Lauf entworfen hat, damit er ihn als Deployment hostet.

resource "google_cloud_run_v2_service" "orders" {
  name     = "orders-api"
  location = "europe-west3"
  ingress  = "INGRESS_TRAFFIC_ALL"

  template {
    service_account = google_service_account.api.email

    scaling {
      min_instance_count = 1
      max_instance_count = 10
    }

    vpc_access {
      egress = "PRIVATE_RANGES_ONLY"
      network_interfaces {
        network    = google_compute_network.shop.id
        subnetwork = google_compute_subnetwork.apps.id
      }
    }

    containers {
      image = "europe-west3-docker.pkg.dev/shop-prod/images/orders-api:2.4.0"

      resources {
        limits = {
          cpu    = "1"
          memory = "512Mi"
        }
      }

      env {
        name  = "RECEIPTS_BUCKET"
        value = google_storage_bucket.receipts.name
      }

      env {
        name = "DB_PASSWORD"
        value_source {
          secret_key_ref {
            secret  = google_secret_manager_secret.db_password.secret_id
            version = "latest"
          }
        }
      }
    }
  }
}

resource "stackit_ske_cluster" "containers" {
  project_id = var.project_id
  name       = "containers"
  node_pools = [{
    name               = "workloads"
    machine_type       = var.containers_machine_type
    minimum            = var.containers_nodes_min
    maximum            = var.containers_nodes_max
    availability_zones = var.availability_zones
  }]
}

• Das Image zieht um, das Manifest schreiben Sie

  Der Lauf schreibt den Cluster. Deployment- und Service-Manifeste werden nicht erzeugt; Name, Umgebung, Ressourcen, Service Account und Netzwerkeinstellungen stehen als nicht übernommen im Code.

• Öffentlicher Zugriff wird markiert

  Die allUsers-Invoker-Bindung löst eine Warnung aus: Heute darf jeder den Dienst aufrufen, und Ihr Ingress auf SKE muss festlegen, wer es künftig darf.

• Skalierungsgrenzen gehören ins Manifest

  Die Quelle hält 1 bis 10 Instanzen. Der Cluster hat noch keinen Workload; Replikas und einen Autoscaler (etwa einen HorizontalPodAutoscaler) legen Sie selbst fest. Der Lauf warnt zudem, dass Scale-to-zero auf SKE KEDA oder Knative braucht; mit mindestens einer Instanz ist dieser Dienst darauf nicht angewiesen.

Jede Einheit, ihre Welle und ihr Ziel

Aus migration/technical-sequencing.md. Eine Einheit zieht erst um, wenn die Einheiten, von denen sie abhängt, umgezogen sind.

Die interessanten Entscheidungen

Jede stammt aus einer Warnung oder einer Zeile „nicht übernommen“, die der Lauf neben den Block geschrieben hat.

• Wie Clients die Datenbank erreichen

  Die Quelldatenbank hat keine öffentliche Adresse. Auf STACKIT hat sie einen Endpunkt mit ACL. Legen Sie die erlaubten Bereiche fest und ob der neue Workload sie über die Egress-Adressen des Clusters erreicht.

• Wiederherstellung und Aufbewahrung

  Point-in-Time-Recovery stellt auf PostgreSQL Flex in eine neue Instanz wieder her, und der Entwurf hält Backups 32 Tage, während sich die Quelle auf den Cloud-SQL-Standard von sieben automatischen Backups verlässt. Prüfen Sie beides gegen Ihr Recovery-Point-Ziel und passen Sie das Recovery-Runbook an, auch dazu, wohin sich Clients nach einer Wiederherstellung verbinden.

• Instanzgröße

  Der Lauf wählt 2.16-replica, weil die Quelle regional ist (Standby in einer zweiten Zone). Er vermerkt selbst, dass keine STACKIT-Seite die Zone jedes Replica-Knotens oder den Ablauf eines Failovers beschreibt. Bestätigen Sie Flavor und benötigte Verfügbarkeit vor dem Apply.

• Schutz vor dem Löschen

  Der Löschschutz der Cloud-SQL-Instanz in Terraform schützt nur den Terraform-Ablauf, und der Entwurf fügt kein Gegenstück hinzu. Ergänzen Sie lifecycle { prevent_destroy = true }, wie der Lauf empfiehlt; die PostgreSQL-Flex-Dokumentation empfiehlt außerdem Instanzschutz für kritische Instanzen.

• Wer die API aufrufen darf

  Die Quelle erlaubt es jedem. Entscheiden Sie, ob der neue Ingress öffentlich bleibt, hinter einem Gateway liegt oder ein Token verlangt.

• Secret und seine Leser

  Das Secret wird von Hand als Schlüssel neu angelegt; der Wert wird nie in den Entwurf kopiert, und die Zugriffsbindung wird nicht übernommen.

• Bucket-Versionierung

  Der Quell-Bucket ist versioniert. Der Lauf hält fest, dass STACKIT Object Storage Versionierung über die S3-API unterstützt, die Bucket-Ressource dafür aber kein Attribut hat; der Entwurfsblock setzt daher nur Name und Projekt. Schalten Sie die Versionierung ein, sobald der Bucket existiert; danach lässt sie sich nur noch aussetzen.

• Datenumzug

  migration/data-movement.md führt Datenbank und Bucket als Entscheidungen ohne gewähltes Verfahren, weil die Quelle weder Datenmenge noch tolerierte Ausfallzeit nennt. Die Begründungen der Einheiten nennen pg_dump mit pg_restore oder logische Replikation für die Datenbank und rclone für den Bucket.

Wo Sie jede Antwort lesen

index.html

Die Zusammenfassung und die Entscheidungsseiten, offline

assessment.json

Jede Einheit mit Klasse, Ziel, Begründung und Befunden

terraform/

Der STACKIT-Entwurf, eine Datei je Bereich

migration/technical-sequencing.md

Die Wellen aus der Tabelle oben

migration/data-movement.md

Datenbank und Bucket mit den offenen Datenentscheidungen

execution/manual/actions.md

Die 16 Arbeitspakete manueller Schritte, jeweils mit Verantwortlichem

engineering/architect-report.md

Befunde, Validierungsmatrix und was nicht belegt ist

Fragen, die Architekten zu diesem Lauf stellen

Quellen

• Google Cloud: Was ist Cloud Run?
• Google Cloud: Überblick über Cloud SQL for PostgreSQL
• STACKIT-Dokumentation: PostgreSQL Flex
• STACKIT-Dokumentation: Kubernetes Engine (SKE)
• Google Cloud: On-Demand- und automatische Backups erstellen und verwalten
• STACKIT-Dokumentation: PostgreSQL Flex sichern und klonen