GCP-Terraform zu STACKIT-Terraform

Eine echte Konvertierung: Cloud SQL zu PostgreSQL Flex

Die Datenbank der Dynamic Python Web App von Google Cloud, unverändert bewertet mit einer Variablendatei aus einer Zeile (project_id = "example-project"). Links steht die Cloud-SQL-Instanz genau so, wie Google sie veröffentlicht, rechts der Block genau so, wie StackToIT ihn im Lauf geschrieben hat. Die Kommentare, die der Entwurf über jedem Block führt, sind hier weggelassen.

resource "google_sql_database_instance" "postgres" {
  name                = var.random_suffix ? "${var.instance_name}-${random_id.suffix.hex}" : var.instance_name
  database_version    = "POSTGRES_14"
  project             = var.project_id
  region              = var.region
  deletion_protection = false

  settings {
    tier        = "db-custom-2-4096" # 2 CPU, 4GB Memory
    user_labels = var.labels
  }
  depends_on = [module.project_services]

}

resource "stackit_postgresflex_instance" "postgres" {
  project_id = var.project_id
  name       = "postgres"
  version    = "14"
  flavor_id  = "2.4"
  storage = {
    class = var.postgresflex_storage_class
    size  = var.postgres_storage_size
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.postgres_allowed_cidrs
  }
  retention_days = 32
}

• Engine, Version und Größe übernommen

  Aus POSTGRES_14 wird eine PostgreSQL-Flex-Instanz in Version 14. Das Tier db-custom-2-4096 (2 CPU, 4 GB Arbeitsspeicher) wird zum Flavor 2.4, also 2 vCPU und 4 GiB auf einem einzelnen Knoten im eu01-Katalog vom 18. Oktober 2026.

• Backups und Aufbewahrung

  Die Quelle nennt keine Startzeit für Backups. Der Entwurf setzt deshalb den Standard 02:00 täglich (0 2 * * *) und sagt das offen. Die Aufbewahrung der Quelle ist statisch nicht sichtbar; retention_days steht auf 32, dem STACKIT-Minimum (32 bis 90).

• Werte, über die Sie entscheiden, werden zu Variablen

  Die Quelle nennt keine Datenträgergröße. Ein Cloud-SQL-Datenträger wächst von selbst, ein PostgreSQL-Flex-Speicher hat eine feste Größe: postgres_storage_size ist eine Variable (5 bis 4000 GB), die Sie nach einem Blick auf den aktuellen Datenträger setzen. Auch die Speicherklasse und die erlaubten CIDRs, die den Endpunkt der Instanz per ACL begrenzen, sind Variablen.

• Jede Eigenschaft erfasst

  Von den 12 relevanten Eigenschaften dieser Cloud-SQL-Einheit (Instanz, Datenbank und Benutzer) sind 6 übernommen oder erklärt und 6 als nicht übernommen benannt: die Labels, das Benutzerpasswort, beide Namen und beide Löschrichtlinien ABANDON. Keine bleibt unerfasst. STACKIT erzeugt das Benutzerpasswort, und Benutzer und Datenbank legen Sie mit stackit_postgresflex_user und stackit_postgresflex_database an.

Zweite Konvertierung: Cloud-Run-Dienst zu STACKIT Kubernetes Engine

STACKIT kennt kein Cloud Run, deshalb wird der Django-API-Dienst zu einem Workload auf STACKIT Kubernetes Engine. Links steht der Dienst genau so, wie Google ihn veröffentlicht. Rechts stehen die Kubernetes-Manifeste, die StackToIT dafür geschrieben hat; sie laufen auf dem Cluster stackit_ske_cluster.containers aus terraform/kubernetes.tf, der auch den Migrationsjob trägt.

resource "google_cloud_run_v2_service" "server" {
  name     = var.random_suffix ? "${var.service_name}-${random_id.suffix.hex}" : var.service_name
  location = var.region

  deletion_protection = false

  template {
    service_account = google_service_account.server.email
    containers {
      image = local.server_image
      env {
        name = "DJANGO_ENV"
        value_source {
          secret_key_ref {
            secret  = google_secret_manager_secret.django_settings.secret_id
            version = "latest"
          }
        }
      }
      env {
        name  = "PYTHONPATH"
        value = ""
      }
      env {
        name  = "DJANGO_SETTINGS_MODULE"
        value = "avocano_api.settings"
      }
      # These variables are a standard part of OpenTelemetry SDK configuration.
      # Details are available at
      # https://opentelemetry.io/docs/reference/specification/sdk-environment-variables/#exporter-selection
      env {
        name  = "OTEL_METRICS_EXPORTER"
        value = "none"
      }
      env {
        name  = "OTEL_TRACES_EXPORTER"
        value = "gcp_trace"
      }
      env {
        name  = "OTEL_PYTHON_EXCLUDED_URLS"
        value = "healthy"
      }
      # Supply the custom suffix, if used, to support automated CSRF code in application settings
      env {
        name  = "DEPLOYMENT_SUFFIX"
        value = var.random_suffix ? random_id.suffix.hex : ""
      }
      volume_mounts {
        name       = "cloudsql"
        mount_path = "/cloudsql"
      }
      liveness_probe {
        http_get {
          path = "/healthy"
        }
      }
    }
    labels = var.labels
    volumes {
      name = "cloudsql"
      cloud_sql_instance {
        instances = [google_sql_database_instance.postgres.connection_name]
      }
    }
  }
  traffic {
    percent = 100
    type    = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
  }

  depends_on = [
    google_secret_manager_secret_version.django_settings
  ]

  lifecycle {
    ignore_changes = [
      scaling,
    ]
  }
}

apiVersion: v1
kind: ConfigMap
metadata:
  name: server-env
  labels:
    app.kubernetes.io/name: server
data:
  DEPLOYMENT_SUFFIX: "" # fill in: the value is not copied from the source
  DJANGO_SETTINGS_MODULE: "" # fill in: the value is not copied from the source
  OTEL_METRICS_EXPORTER: "" # fill in: the value is not copied from the source
  OTEL_PYTHON_EXCLUDED_URLS: "" # fill in: the value is not copied from the source
  OTEL_TRACES_EXPORTER: "" # fill in: the value is not copied from the source
  PYTHONPATH: "" # fill in: the value is not copied from the source
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  labels:
    app.kubernetes.io/name: server
spec:
  replicas: REQUIRED_SERVER_REPLICAS
  selector:
    matchLabels:
      app.kubernetes.io/name: server
  template:
    metadata:
      labels:
        app.kubernetes.io/name: server
    spec:
      containers:
      - name: container-1
        image: "us-docker.pkg.dev/hsa-public/containers/terraform-python-dynamic-webapp/server:v1.13.4"
        ports:
        - containerPort: 8080
          protocol: TCP
        env:
        - name: PORT
          value: "8080"
        - name: DJANGO_ENV
          valueFrom:
            secretKeyRef:
              name: server-secrets
              key: DJANGO_ENV
        - name: PYTHONPATH
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: PYTHONPATH
        - name: DJANGO_SETTINGS_MODULE
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: DJANGO_SETTINGS_MODULE
        - name: OTEL_METRICS_EXPORTER
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: OTEL_METRICS_EXPORTER
        - name: OTEL_TRACES_EXPORTER
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: OTEL_TRACES_EXPORTER
        - name: OTEL_PYTHON_EXCLUDED_URLS
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: OTEL_PYTHON_EXCLUDED_URLS
        - name: DEPLOYMENT_SUFFIX
          valueFrom:
            configMapKeyRef:
              name: server-env
              key: DEPLOYMENT_SUFFIX
        livenessProbe:
          httpGet:
            path: "/healthy"
            port: 8080
        readinessProbe:
          tcpSocket:
            port: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: server
  labels:
    app.kubernetes.io/name: server
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: server
  ports:
  - name: p8080-tcp
    port: 8080
    targetPort: 8080
    protocol: TCP

• Image, Port und Health Check übernommen

  Das Container-Image und der Liveness-Pfad /healthy stammen direkt aus dem Dienst. Die Quelle nennt keinen Port, deshalb nimmt der Entwurf 8080, den Standard von Cloud Run, und ergänzt einen Readiness-Check auf diesem Port.

• Secret und Umgebung getrennt

  DJANGO_ENV stammt aus einem Secret-Manager-Secret und wird zur Referenz auf ein Kubernetes-Secret, server-secrets, das Sie anlegen. Die fünf einfachen Variablen werden zu den Schlüsseln der ConfigMap server-env; ihre Werte kopiert der Entwurf nicht, die tragen Sie ein.

• Ein Cluster für Dienst und Job

  Der Cluster stackit_ske_cluster.containers hat einen Node Pool namens workloads. Maschinentyp sowie minimale und maximale Knotenzahl sind Variablen ohne Standardwert, die Zonen stehen standardmäßig auf eu01-1, eu01-2 und eu01-3. Der Migrationsjob wird zu einem Kubernetes Job auf demselben Cluster.

• Replikazahl angehalten, Erreichbarkeit offen

  Die Zahl der Pods ist eine Pflichteingabe, deshalb hält das Apply, bis Sie sie setzen: 0 für den Apply-Schritt, danach die Zahl, die die Quelle fährt, sobald die Daten geladen sind. Der Service ist ein ClusterIP und macht noch nichts erreichbar: Ein Ingress oder ein Service vom Typ LoadBalancer samt Zertifikat und DNS-Eintrag ist Ihre Entscheidung.

• Als nicht übernommen benannt

  Das Dienstkonto der Revision, die Labels, die Verkehrsaufteilung zwischen Revisionen, der Löschschutz und das Volume der Cloud-SQL-Verbindung. Die Pods laufen unter dem Standard-ServiceAccount, bis Sie die Identität festlegen, und erreichen die Datenbank über ihre Netzwerkadresse.

So funktioniert die Konvertierung

1. 01

   Umgebung auflösen

   18 Dateien und das Registry-Modul project_services 18.0.0 werden zu einem Abhängigkeitsgraphen: 37 Ressourcen, 11 Migrationseinheiten und 29 Abhängigkeiten, offline gelesen. Fünf weitere Einheiten hängen von Variablen ab und stehen erst fest, wenn OpenTofu plant.

2. 02

   Pro Ressource entscheiden

   Eine versionierte Regelbasis weist jeder Ressource anhand ihrer tatsächlichen Konfiguration ein STACKIT-Ziel und eine Migrationsklasse zu, mit einem Konfidenzwert.

3. 03

   STACKIT-Code schreiben

   10 Ressourcenblöcke in Dateien pro Bereich: Daten, Kubernetes, Messaging, Speicher, Identität und Sicherheit, dazu 13 Variablen, Kubernetes-Manifeste und der auf 0.121.0 festgelegte STACKIT-Provider. Vier Einheiten werden als Module vorgeschlagen, die ausgeschaltet bleiben.

4. 04

   Prüfen und nachverfolgen

   StackToIT hat seine 20 Entwurfsprüfungen ausgeführt, und keine hat einen Verstoß gefunden. OpenTofu 1.13.1 hat tofu init und tofu validate auf den Entwurf angewendet und ihn akzeptiert. Jeder Block trägt eine Trace-ID, die zu seiner Quellressource zurückführt.

Was der Lauf gemeldet hat

Ausgewählte Zeilen der Konsolenzusammenfassung dieses Laufs, wörtlich.

Source files:           18
Resources scanned:      37  (34 in the root module · 3 inside 1 module call)
Migration units:        11 known-present (11 instances) · 5 conditional
Unit dependencies:      29
Modules:                1 module call (1 external, 0 local): 1 loaded, 0 not downloaded, 0 invalid
Source checks:          Built-in source checks passed — OpenTofu validation of the source did not run (LOCK_FILE)

DIRECT              0  
RECONFIGURE         6  ████████████████ 54%
REPLATFORM          2  █████ 18%
CONTAINERIZE        2  █████ 18%
REDESIGN            0  
MANUAL_REVIEW       1  ██ 9%
BLOCKED             0    (the mapping class BLOCKED, not the execution blockers, which Migration readiness counts)
Confidence  HIGH 0 · MEDIUM 10 · LOW 1

69 source properties checked across 11 generated units: 29 carried or explained, 40 NOT CARRIED, 0 unaccounted — see engineering/architect-report.md.

STACKIT draft (this folder/terraform): 11 units generated · 4 proposed, switched off · 0 need no resource · 1 left for the architect · 13 variables
  StackToIT draft checks: PASSED (20 checks, none found a violation)
  OpenTofu validation: PASSED (tofu init -backend=false and tofu validate accepted the draft; tofu 1.13.1)
tofu validate: STATIC_TERRAFORM_VALIDATION_PASSED — deployment readiness and live target behaviour not verified

Next action   Allow the calls of STACKIT APIs that are not generally available — Owner: Platform Architect · details: index.html

• 37 Ressourcen, 11 Einheiten, 5 zur Planzeit

  34 Ressourcen liegen im Root-Modul und 3 im Registry-Modul. Untergeordnete Ressourcen gehören zur Einheit, der sie dienen, und 8 unterstützende Ressourcen werden von den Einheiten gelesen, die sie nutzen. Fünf weitere Einheiten gibt es nur, wenn eine Variable zur Planzeit greift; sie sind ebenfalls bewertet und entsprechend gekennzeichnet.

• 11 von 16 Einheiten im Entwurf

  11 Einheiten haben erzeugte STACKIT-Ressourcen, geschrieben als 10 Blöcke. 4 sind vorgeschlagen und bleiben ausgeschaltet, bis Sie entscheiden, und das Firebase-Projekt bleibt bei Ihrem Architekten. Der Entwurf hat 13 Variablen.

• 69 Eigenschaften, 0 unerfasst

  29 Eigenschaften sind übernommen oder erklärt, und 40 sind als nicht übernommen benannt, in der Datei engineering/not-carried.csv. Die Prüfung umfasst die 11 erzeugten Einheiten.

• Eine Klasse für jede Einheit

  Der Lauf hat 6-mal RECONFIGURE, 2-mal REPLATFORM, 2-mal CONTAINERIZE und 1-mal MANUAL_REVIEW festgelegt, und assessment.json nennt den Grund für jede Einheit.

• Die nächste Aktion hat einen Verantwortlichen

  Der Plan hat 78 Schritte. 10 der 12 automatisierten Schritte sind frei von Entscheidungen und warten nur auf Werte wie project_id. 6 Entscheidungen sind offen; die erste, beim Platform Architect, ist die Freigabe von STACKIT-APIs, die nicht allgemein verfügbar sind. 27 Eingabeanfragen sind offen.

Wie die 11 Einheiten und die 5 zur Planzeit entschieden wurden

Klassen, wie der Lauf sie festgelegt hat. Die ersten 11 Zeilen sind die Einheiten, die in der Quelle stehen; die letzten 5 gibt es nur, wenn eine Variable beim Planen von OpenTofu greift, und sie greift mit den Standardwerten dieses Laufs.

Was in terraform/ landet

Das STACKIT-Terraform dieses Laufs, so gegliedert, wie ein Plattformteam es pflegt.

data.tf

PostgreSQL-Flex-Instanz für die Cloud-SQL-Instanz

kubernetes.tf

Ein SKE-Cluster mit Node Pool für Cloud-Run-Dienst und -Job

kubernetes/

Manifeste für server (ConfigMap, Deployment, Service) und migrate (Job)

messaging.tf

RabbitMQ-Instanz für das Pub/Sub-Topic

rabbitmq/

Topologiedatei und Skript für Exchanges und Queues, die der Provider nicht anlegt

storage.tf

Object-Storage-Bucket für den Media-Bucket

identity.tf

Die 4 Dienstkonten

security.tf

Secrets-Manager-Instanz und der Migrationsbenutzer, der die Secrets schreibt

proposals.tf, proposals/

8 Module, jedes hinter einem Schalter, der aus bleibt, bis Sie entscheiden

handover/

Vorbereitungshinweise für den Datenbankumzug, die Medienkopie und den Clusterzugang

variables.tf

Die 13 Werte, die Ihr Team setzt oder bestätigt, jeweils mit Beschreibung

terraform.tf

Festgelegter STACKIT-Provider

README.md

Was der Entwurf enthält, welche Dienste zuerst freizuschalten sind, die Sicherheits-Checkliste und was nicht übernommen wird

Was zum Terraform dazukommt

Derselbe Lauf schreibt das Material, mit dem Ihre Architekten und Betreiber arbeiten.

assessment.json

Pro Einheit: Klasse, Konfidenz, STACKIT-Ziel, Begründung und Befunde

engineering/not-carried.csv

Die 40 Eigenschaften, die der Entwurf nicht übernimmt, je eine Zeile mit Begründung

engineering/trace/

Eine Trace-Datei pro Entwurfsdatei, von jedem Block zurück zur Quelle

architecture/

Diagramme der aktuellen und der Zielarchitektur, der Netzwerksicherheit und der Datenflüsse

migration/technical-sequencing.md

4 Wellen, aus den Abhängigkeiten zwischen den Einheiten berechnet

execution/

Das Ausführungspaket: 24 Arbeitspakete mit 64 manuellen Schritten, 2 API-Schritte, ein Deploy-Skript und ein Pipeline-Beispiel

decisions.json

Das strukturierte Entscheidungsregister, in diesem Lauf mit 6 zu treffenden Entscheidungen

financial/

Preiszeilen und Abdeckung: 2 von 8 STACKIT-Zeilen bepreist, kein Vergleich ausgewiesen

review/

Vorlagen für Ihre Antworten und Zielwerte, die der nächste Lauf einliest

Fragen aus Plattformteams

Quellen

• StackToIT-Beispiel: Google Cloud Dynamic Python Web App, der vollständige Lauf
• GitHub: GoogleCloudPlatform/terraform-dynamic-python-webapp (Apache-2.0, festgelegter Commit)
• STACKIT-Dokumentation: Terraform-Provider
• STACKIT-Dokumentation: PostgreSQL Flex
• STACKIT-Dokumentation: Kubernetes Engine
• STACKIT-Dokumentation: RabbitMQ
• Google-Cloud-Dokumentation: Einführung in Cloud SQL
• Google-Cloud-Dokumentation: Was ist Cloud Run