Google Cloud Functions zu STACKIT

Die Migration, Schritt für Schritt

Die Schritte folgen den Einheiten des Beispiellaufs in der Reihenfolge seiner Wellen.

1. 01

   Funktionen nach Generation und Trigger auflisten

   Google dokumentiert zwei Generationen von Cloud Functions; die zweite Generation steht in der Cloud-Run-Dokumentation. Halten Sie je Funktion Trigger (HTTP, Pub/Sub, Storage-Ereignis, Zeitplan), Laufzeit, Speicher, Timeout, Instanzgrenzen, Ingress-Einstellung, Service Account und Secrets fest.

2. 02

   Zielplattform wählen

   Eine Cloud-Foundry-App passt zu Code, den Sie mit einem Buildpack pushen; ein Container auf SKE passt zu einer Funktion, die schon als Image geliefert wird oder neben anderen Workloads laufen soll. Der Lauf schlägt Cloud Foundry für die Funktion und SKE für den Zeitplan vor; ob Sie auf eine Plattform vereinheitlichen, entscheiden Sie.

3. 03

   Zuerst die Grundlagen umziehen

   Service Account, Quell-Bucket und Topic liegen in Welle 1 des Laufs; das Secret folgt in Welle 2. Der Service Account wird zum STACKIT-Service-Account, der Bucket zum STACKIT-Object-Storage-Bucket, das Secret zu einem Schlüssel im Secrets Manager.

4. 04

   Den Trigger neu schreiben

   Das Topic wird zum RabbitMQ-Exchange, das Abonnement zur Queue. Der Funktionscode wechselt vom Pub/Sub-Ereignis zu einem AMQP-Consumer; Bestätigung und Wiederholung legen Sie bewusst fest.

5. 05

   Die App pushen

   Schreiben Sie das Manifest aus der Liste der nicht übernommenen Einstellungen des Laufs. Im Beispiel sind das der App-Name send-receipt, 256 MB Speicher, höchstens 5 Instanzen, die Variable MAIL_FROM und das Secret MAIL_API_KEY; für das Timeout von 60 Sekunden braucht es eine eigene Entscheidung. Pushen Sie die App in einen Space der entworfenen Organisation.

6. 06

   Den Zeitplan neu anlegen

   Schreiben Sie den CronJob oder einen Cloud-Foundry-Task, der den neuen Endpunkt nach dem alten Zeitplan aufruft. Die Endpunktadresse ändert sich, also auch das Ziel des Zeitplans.

7. 07

   Testen, umstellen, alte Funktion behalten

   Senden Sie Testnachrichten, vergleichen Sie das Ergebnis mit der noch laufenden Funktion, stellen Sie die Publisher um und entfernen Sie die alte Funktion nach der Abnahme. Das ist Praxis, kein Schritt, den der Lauf ausführt.

Eine Pub/Sub-Funktion, umgewandelt

Eine für diese Seite geschriebene Umgebung, am 4. November 2026 von StackToIT bewertet: eine Funktion der zweiten Generation mit Pub/Sub-Trigger, ihr Service Account, ein Secret, ein Quell-Bucket und ein nächtlicher Cloud-Scheduler-Job. Links die Funktion der Eingabe, rechts der Block, den der Lauf dafür entworfen hat; die Prüfkommentare über dem Block sind hier ausgelassen.

resource "google_cloudfunctions2_function" "receipt" {
  name     = "send-receipt"
  location = "europe-west3"

  build_config {
    runtime     = "python312"
    entry_point = "handle_paid_order"
    source {
      storage_source {
        bucket = google_storage_bucket.fn_source.name
        object = google_storage_bucket_object.receipt_zip.name
      }
    }
  }

  service_config {
    available_memory      = "256M"
    timeout_seconds       = 60
    max_instance_count    = 5
    service_account_email = google_service_account.fn.email
    ingress_settings      = "ALLOW_INTERNAL_ONLY"

    environment_variables = {
      MAIL_FROM = "orders@example.com"
    }

    secret_environment_variables {
      key        = "MAIL_API_KEY"
      project_id = "shop-events-prod"
      secret     = google_secret_manager_secret.mail_key.secret_id
      version    = "latest"
    }
  }

  event_trigger {
    trigger_region = "europe-west3"
    event_type     = "google.cloud.pubsub.topic.v1.messagePublished"
    pubsub_topic   = google_pubsub_topic.orders_paid.id
    retry_policy   = "RETRY_POLICY_RETRY"
  }
}

resource "stackit_scf_organization" "migrated_apps" {
  project_id = var.project_id
  name       = "migrated-apps"
}

• Eine Organisation, keine App

  Der Entwurf legt die Cloud-Foundry-Organization an, die die migrierten Apps beherbergt. Die App selbst wird mit einem Manifest in einen Space gepusht, das der Lauf nicht erzeugt.

• Was in Kommentaren steht

  Name, Quellort, Speicher, Instanzen, Umgebung, Secrets und Netzwerkeinstellungen stehen als nicht übernommen im Code, damit Sie sie ins Manifest kopieren können.

• Interner Ingress wird benannt

  Eine Cloud-Foundry-App ist über ihre Route erreichbar. Der Lauf hält fest, dass interner Ingress nicht übernommen wird und Sie einschränken müssen, wer die App erreicht.

Der Trigger und der Zeitplan

Die Funktion läuft nicht allein. Ihr Topic und ihr Scheduler-Job werden zu einem Message-Broker und einem Cron-Job, und der Lauf entwirft die Plattformen, die sie dafür brauchen. Jeder Eingabeblock steht neben dem Block, den der Lauf dafür geschrieben hat; die Prüfkommentare sind ausgelassen.

resource "google_pubsub_topic" "orders_paid" {
  name = "orders-paid"
}

resource "stackit_rabbitmq_instance" "messaging" {
  project_id = var.project_id
  name       = "messaging"
  plan_name  = var.rabbitmq_plan_name
  version    = var.rabbitmq_version
  parameters = {
    sgw_acl = join(",", var.rabbitmq_allowed_cidrs)
  }
}

resource "google_cloud_scheduler_job" "nightly" {
  name      = "nightly-digest"
  region    = "europe-west3"
  schedule  = "0 3 * * *"
  time_zone = "Europe/Berlin"

  http_target {
    uri         = google_cloudfunctions2_function.receipt.service_config[0].uri
    http_method = "POST"
  }
}

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
  }]
}

• Topic zu Exchange

  Das Topic wird zu einem Exchange einer gemeinsamen RabbitMQ-Instanz, von Hand in RabbitMQ angelegt; Abonnements werden zu Queues.

• Job zu CronJob

  Der Scheduler-Job wird zu einem Kubernetes-CronJob auf SKE, der den neuen Endpunkt der Funktion nach demselben Zeitplan aufruft: 0 3 * * * in Europe/Berlin. Sein Manifest wird nicht erzeugt; Name, HTTP-Methode, Body, Header, Frist und Wiederholungsregel tragen Sie von Hand ein.

So wird die Funktionsumgebung zugeordnet

Eine Zeile je Einheit des Laufs: acht Ressourcen gelesen, sechs Migrationseinheiten.

Klassen, wie der Lauf sie entschieden hat. Die Zugriffsbindung des Secrets und das Quellarchiv-Objekt sind keine eigenen Einheiten.

Entscheidungen, die beim Architekten liegen

Offene Punkte des Laufs, zu finden in execution/manual/actions.md.

• Anwendungsidentität

  Legen Sie fest, wie die App an Zugangsdaten kommt. Funktionen, die den Metadatenserver nutzten, brauchen explizite STACKIT-Zugangsdaten oder Workload-Identität; der Lauf führt das für die Funktion und für ihren Service Account auf.

• Netzwerk-Erreichbarkeit

  Die Quellfunktion nimmt nur internen Verkehr an. Entscheiden Sie, wer die Cloud-Foundry-Route erreichen darf, und prüfen Sie die offenen Einstellungen, die der Lauf dem Netzwerkarchitekten zuweist.

• Scale-to-zero und Abrechnung

  Skalierung und Abrechnung je Aufruf entfallen. Dimensionieren Sie Instanzen nach der Last und akzeptieren Sie eine App, die auch im Leerlauf läuft.

• Secret-Einstellungen

  Legen Sie das Secret als Schlüssel in der entworfenen Secrets-Manager-Instanz neu an und entscheiden Sie, wer es lesen darf; die Einstellungen überlässt der Lauf dem Sicherheitsarchitekten.

• Daten des Quell-Buckets

  Der Lauf führt den Datenumzug des Buckets als Entscheidung ohne gewählten Mechanismus. Enthält der Bucket nur ein Deployment-Archiv, kann ein Neubau aus dem Quellcode einfacher sein als das Kopieren.

• Messaging-Semantik

  Der Trigger im Beispiel setzt retry_policy = RETRY_POLICY_RETRY. Bestätigungsfristen, Wiederholungen und Dead-Letter-Topics von Pub/Sub entsprechen laut Zuordnung des Laufs Bestätigungen, Requeueing und Dead-Letter-Exchanges. Legen Sie sie je Queue fest und machen Sie den Consumer robust gegen doppelt zugestellte Nachrichten.

Fragen von Entwicklerteams

Quellen

• Google Cloud: Überblick über Cloud Run functions
• Google Cloud: Was ist Cloud Run?
• STACKIT-Dokumentation: Cloud Foundry
• STACKIT-Dokumentation: Kubernetes Engine (SKE)
• STACKIT-Dokumentation: Cloud-Foundry-FAQ