Google Pub/Sub naar STACKIT RabbitMQ

Twee topics, drie subscriptions, beoordeeld

Een kleine omgeving die voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld: een topic met een pull-subscription met volgorde, een retrybeleid en een dead-letterbeleid, een push-subscription op hetzelfde topic en een dead-lettertopic met een eigen inspectiesubscription. Links: de invoer. Rechts: de ene resource die de engine voor dit alles schreef.

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

• Vijf resources, twee eenheden

  De drie subscriptions zijn geen eigen eenheden. Ze reizen mee als facetten van hun topic, dus de run telt 5 resources en 2 eenheden, beide ingedeeld als REPLATFORM met zekerheidsniveau MEDIUM. Het dead-lettertopic staat in golf 1 en het hoofdtopic in golf 2, omdat het hoofdtopic ervan afhangt.

• Eén instance voor alle topics

  Het concept schrijft één stackit_rabbitmq_instance voor alle gemigreerde topics. De toegangslijst is de variabele rabbitmq_allowed_cidrs, die geen standaardwaarde heeft en de standaardranges van STACKIT vervangt, dus u noemt de clients die echt verbinden.

Wat het concept niet overneemt

De commentaarregels boven het instanceblok in terraform/messaging.tf, één per topic en subscription, gevolgd door de waarschuwingen over push en volgorde. Ze vormen de werklijst voor de verhuizing: exchanges, queues en leveringsregels maakt een persoon aan in RabbitMQ.

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

Hoe Pub/Sub-concepten overeenkomen met RabbitMQ

De bereiken van Pub/Sub komen uit de pagina met subscriptioneigenschappen van Google; de run noemt de doelzijde. Pub/Sub bewaart berichten tot 31 dagen, dus een team dat berichten opnieuw afspeelt, heeft op RabbitMQ een eigen ontwerp nodig.

De stappen van de verhuizing, in volgorde

1. 01

   1. Inventariseer de topics en wie ermee communiceert

   Voer het assessment uit op de Terraform die uw topics en subscriptions aanmaakt. Topics die handmatig of met een andere tool zijn aangemaakt, staan niet in de bron en worden niet gezien; vergelijk het resultaat dus met de topics die uw project werkelijk vermeldt.

2. 02

   2. Zet eerst de dead-letterkant op

   technical-sequencing.md in de migratiemap zet het dead-lettertopic in golf 1 en het topic dat ervan afhangt in golf 2. Bouw dezelfde volgorde op RabbitMQ: het dead-letterdoel moet bestaan voordat een queue ernaar verwijst.

3. 03

   3. Richt de instance in en beperk de toegangslijst

   Stel het plan, de versie en rabbitmq_allowed_cidrs in, drie van de variabelen die de run aan u overlaat. De eigen documentatie van STACKIT raadt aan de standaardtoegangslijst na het aanmaken te beoordelen en te beperken tot de adressen die uw applicaties gebruiken.

4. 04

   4. Declareer exchanges, queues en bindings

   Het concept genereert ze niet. Declareer voor elke subscription een queue en bind die. Voor dead letters documenteert RabbitMQ een policy-sleutel, dead-letter-exchange, en een argument, x-dead-letter-exchange; het raadt de policy aan, omdat argumenten niet kunnen wijzigen zonder applicaties opnieuw uit te rollen.

5. 05

   5. Vertaal de leveringsregels

   Koppel de bevestigingstermijn aan bevestigingen door consumers en het maximale aantal leveringspogingen aan een leveringslimiet. Op quorum queues behandelt RabbitMQ een bericht dat vaker terugkomt dan die limiet als dead letter, met de reden delivery_limit. Schrijf backoff in de consumer.

6. 06

   6. Vervang push en maak consumers idempotent

   Plaats een doorstuurconsumer waar een push-endpoint stond. Pub/Sub levert standaard minstens één keer (at-least-once) en RabbitMQ doet dat ook, dus een consumer die eerder duplicaten verwerkte, moet dat nog steeds doen.

7. 07

   7. Schakel eerst publishers over, dan consumers, en leeg de queues

   Het dataverplaatsingsbestand van deze run meldt NOT APPLICABLE: een topicdienst staat niet als stateful vermeld, dus berichten onderweg worden niet bijgehouden. Leeg de oude subscriptions zelf voordat u ze uitfaseert (algemene praktijk).

Beslissingen die de architect neemt

• Type queue

  Klassieke of quorum queues veranderen hoe een leveringslimiet en dead lettering werken. De run kiest niet.

• Eén instance of meerdere

  Het concept host elk topic op één instance. Aparte instances per omgeving of per team bepaalt u zelf.

• Grootte van het plan

  rabbitmq_plan_name heeft geen standaardwaarde. De bron noemt geen berichtsnelheid, dus niets in de run bepaalt de grootte.

• Replay

  Bepaal of bevestigde berichten leesbaar moeten blijven en hoe lang.

• Cutovermethode

  Een tijdlang naar beide systemen publiceren, of stoppen en overschakelen. De run voert geen cutover uit en geeft geen tijdsinschatting.

Vragen van teams

Bronnen

• STACKIT-documentatie: RabbitMQ
• STACKIT-documentatie: concepten van RabbitMQ
• Google Cloud-documentatie: Pub/Sub-subscriptions
• Google Cloud-documentatie: eigenschappen van Pub/Sub-subscriptions
• RabbitMQ-documentatie: Dead Letter Exchanges