Google Pub/Sub zu STACKIT RabbitMQ

Zwei Topics, drei Subscriptions, bewertet

Eine kleine, für diese Seite geschriebene Umgebung, am 4. November 2026 von StackToIT bewertet: ein Topic mit einer Pull-Subscription samt Reihenfolge, Retry-Policy und Dead-Letter-Policy, eine Push-Subscription auf demselben Topic sowie ein Dead-Letter-Topic mit einer eigenen Subscription zur Kontrolle. Links die Eingabe, rechts die eine Ressource, die die Engine für all das geschrieben hat.

resource "google_pubsub_topic" "orders" {
  name                       = "orders-created"
  message_retention_duration = "86400s"
}

resource "google_pubsub_topic" "orders_dead" {
  name = "orders-created-dead"
}

resource "google_pubsub_subscription" "billing" {
  name  = "billing-worker"
  topic = google_pubsub_topic.orders.id

  ack_deadline_seconds       = 60
  message_retention_duration = "604800s"
  enable_message_ordering    = true

  retry_policy {
    minimum_backoff = "10s"
    maximum_backoff = "300s"
  }

  dead_letter_policy {
    dead_letter_topic     = google_pubsub_topic.orders_dead.id
    max_delivery_attempts = 5
  }
}

resource "google_pubsub_subscription" "webhook" {
  name  = "partner-webhook"
  topic = google_pubsub_topic.orders.id

  ack_deadline_seconds = 30

  push_config {
    push_endpoint = "https://partner.example.com/hooks/orders"
  }
}

resource "google_pubsub_subscription" "dead_inspect" {
  name  = "dead-letter-inspect"
  topic = google_pubsub_topic.orders_dead.id

  ack_deadline_seconds = 20

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

• Fünf Ressourcen, zwei Einheiten

  Die drei Subscriptions sind keine eigenen Einheiten. Sie werden als Facetten ihres Topics mitgeführt, daher zählt der Lauf 5 Ressourcen und 2 Einheiten, beide REPLATFORM mit Konfidenz MEDIUM. Das Dead-Letter-Topic liegt in Welle 1, das Haupt-Topic in Welle 2, weil es davon abhängt.

• Eine Instanz für alle Topics

  Der Entwurf schreibt genau eine stackit_rabbitmq_instance für alle migrierten Topics. Ihre Zugriffsliste ist die Variable rabbitmq_allowed_cidrs; sie hat keinen Standardwert und ersetzt die STACKIT-Standardbereiche. Tragen Sie also die Clients ein, die sich tatsächlich verbinden.

Was der Entwurf nicht übernimmt

Die Kommentarzeilen über dem Instanzblock in terraform/messaging.tf, eine je Topic und Subscription, danach die Warnungen zu Push und Reihenfolge. Sie sind die Arbeitsliste für den Umzug: Exchanges, Queues und Zustellregeln legt eine Person in RabbitMQ an.

# NOT CARRIED (google_pubsub_topic.orders): message_retention_duration = 86400s, name = orders-created — the topic becomes an exchange and its subscriptions queues of the shared RabbitMQ instance, created in RabbitMQ by hand (not by this draft): names, delivery, retention and push settings are not generated.
# NOT CARRIED (google_pubsub_subscription.billing): ack_deadline_seconds = 60, dead_letter_policy, enable_message_ordering = true, message_retention_duration = 604800s, name = billing-worker, retry_policy — the topic becomes an exchange and its subscriptions queues of the shared RabbitMQ instance, created in RabbitMQ by hand (not by this draft): names, delivery, retention and push settings are not generated.
# NOT CARRIED (google_pubsub_subscription.webhook): ack_deadline_seconds = 30, name = partner-webhook, push_config — the topic becomes an exchange and its subscriptions queues of the shared RabbitMQ instance, created in RabbitMQ by hand (not by this draft): names, delivery, retention and push settings are not generated.
# NOT CARRIED (google_pubsub_topic.orders_dead): name = orders-created-dead — the topic becomes an exchange and its subscriptions queues of the shared RabbitMQ instance, created in RabbitMQ by hand (not by this draft): names, delivery, retention and push settings are not generated.
# NOT CARRIED (google_pubsub_subscription.dead_inspect): ack_deadline_seconds = 20, name = dead-letter-inspect — the topic becomes an exchange and its subscriptions queues of the shared RabbitMQ instance, created in RabbitMQ by hand (not by this draft): names, delivery, retention and push settings are not generated.
# google_pubsub_topic.orders: WARNING pubsub-push: Push subscriptions call HTTP endpoints; RabbitMQ delivers to consumers, so a small forwarding consumer (or the endpoint as consumer) replaces push.
# google_pubsub_topic.orders: WARNING pubsub-ordering: Ordered or exactly-once delivery is enabled; RabbitMQ orders per queue and delivers at least once, so consumers must be idempotent.

Wie Pub/Sub-Konzepte auf RabbitMQ abgebildet werden

Die Pub/Sub-Wertebereiche stammen aus Googles Seite zu den Subscription-Eigenschaften; die Zielseite beschreibt der Lauf. Pub/Sub bewahrt Nachrichten bis zu 31 Tage auf; wer Nachrichten erneut abspielt (Replay), braucht auf RabbitMQ ein eigenes Design.

Die Schritte des Umzugs, der Reihe nach

1. 01

   1. Topics und ihre Gegenstellen erfassen

   Lassen Sie die Bewertung über das Terraform laufen, das Ihre Topics und Subscriptions anlegt. Von Hand oder mit anderen Werkzeugen angelegte Topics stehen nicht in der Quelle und werden nicht gesehen. Gleichen Sie das Ergebnis mit den Topics ab, die Ihr Projekt tatsächlich listet.

2. 02

   2. Zuerst die Dead-Letter-Seite aufbauen

   Die Datei technical-sequencing.md im Migrationsordner legt das Dead-Letter-Topic in Welle 1 und das abhängige Topic in Welle 2. Bauen Sie dieselbe Reihenfolge auf RabbitMQ nach: Das Dead-Letter-Ziel muss existieren, bevor eine Queue darauf verweist.

3. 03

   3. Instanz bereitstellen und Zugriffsliste eingrenzen

   Setzen Sie Plan, Version und rabbitmq_allowed_cidrs, drei der Variablen, die der Lauf Ihnen überlässt. STACKIT empfiehlt in der eigenen Dokumentation, die Standard-Zugriffsliste nach dem Anlegen zu prüfen und auf die Adressen Ihrer Anwendungen zu beschränken.

4. 04

   4. Exchanges, Queues und Bindings anlegen

   Der Entwurf erzeugt sie nicht. Legen Sie je Subscription eine Queue an und binden Sie sie. Für Dead Letter dokumentiert RabbitMQ den Policy-Schlüssel dead-letter-exchange und das Argument x-dead-letter-exchange; RabbitMQ empfiehlt die Policy, weil sich Argumente nicht ohne Neuausrollen der Anwendungen ändern lassen.

5. 05

   5. Zustellregeln übersetzen

   Übertragen Sie die Bestätigungsfrist auf Consumer-Acknowledgements und die maximalen Zustellversuche auf ein Delivery Limit. Bei Quorum Queues stellt RabbitMQ eine Nachricht, die öfter zurückkommt als dieses Limit, als Dead Letter mit dem Grund delivery_limit ab. Den Backoff schreiben Sie in den Consumer.

6. 06

   6. Push ersetzen und Consumer idempotent machen

   Setzen Sie dort, wo ein Push-Endpunkt war, einen weiterleitenden Consumer ein. Pub/Sub liefert standardmäßig mindestens einmal, RabbitMQ ebenso; ein Consumer, der bisher Duplikate verkraften musste, muss das weiterhin können.

7. 07

   7. Publisher, dann Consumer umstellen, Subscriptions leeren

   In der Datei data-movement.md steht für diesen Lauf „NOT APPLICABLE“: Ein Topic-Dienst ist nicht als zustandsbehaftet aufgeführt, daher werden Nachrichten, die noch unterwegs sind, nicht erfasst. Leeren Sie die alten Subscriptions selbst, bevor Sie sie stilllegen (allgemeine Praxis).

Entscheidungen, die Ihre Architekten treffen

• Queue-Typ

  Klassische oder Quorum Queues verändern, wie Delivery Limit und Dead Lettering wirken. Der Lauf wählt nicht.

• Eine Instanz oder mehrere

  Der Entwurf legt alle Topics auf eine Instanz. Getrennte Instanzen je Umgebung oder Team entscheiden Sie.

• Plangröße

  rabbitmq_plan_name hat keinen Standardwert. Die Quelle nennt keine Nachrichtenrate, also dimensioniert der Lauf nichts.

• Replay

  Legen Sie fest, ob bestätigte Nachrichten lesbar bleiben müssen und wie lange.

• Cutover-Verfahren

  Eine Zeit lang an beide Systeme publizieren oder anhalten und umstellen. Der Lauf führt keinen Cutover durch und nennt keine Zeitschätzung.

Fragen aus den Teams

Quellen

• STACKIT-Dokumentation: RabbitMQ
• STACKIT-Dokumentation: RabbitMQ-Konzepte
• Google-Cloud-Dokumentation: Pub/Sub-Subscriptions
• Google-Cloud-Dokumentation: Eigenschaften von Pub/Sub-Subscriptions
• RabbitMQ-Dokumentation: Dead Letter Exchanges