AZURE SERVICE BUS → STACKIT RABBITMQ
Azure Service Bus zu STACKIT RabbitMQ
Service Bus wird per Replatforming zu STACKIT RabbitMQ migriert: Eine RabbitMQ-Instanz nimmt Queues und Exchanges auf, und die Clients wechseln vom Service-Bus-SDK zu einem AMQP-0-9-1-Client. StackToIT schreibt die Instanz, führt jede nicht übernommene Queue- und Topic-Einstellung auf und benennt die Service-Bus-Funktionen, die RabbitMQ anders behandelt.
Die Schritte in der Reihenfolge
1. Entitäten und Funktionen erfassen
Listen Sie Namespaces, Queues, Topics, Subscriptions und deren Regeln auf. Notieren Sie je Eintrag Sessions, Duplikaterkennung, Dead-Lettering, Nachrichtenlebensdauer und Zustelllimits. Diese Einstellungen bestimmen, wie viel Code sich ändert.
2. Terraform bewerten
Die Bewertung macht aus jedem Namespace samt Queues und Topics eine Einheit und zeigt, was der Entwurf übernimmt und was nicht.
3. RabbitMQ-Instanz anlegen
Setzen Sie Projekt, Plan, Version und die Clients, die sich verbinden dürfen. Die Zugriffsliste ersetzt den Standardbereich; daher tragen Sie Ihre Clients ein.
4. Topologie einrichten
Richten Sie Queues, Exchanges und Bindings in der Instanz ein, aus der Anwendung oder per Deployment-Skript (gängige Praxis). Der Entwurf legt nur die Instanz an und führt jede Queue- und Topic-Einstellung als nicht übernommen.
5. Clients umstellen
Producer und Consumer wechseln zu einer AMQP-0-9-1-Clientbibliothek, einem neuen Host, einer TLS-Einstellung und den Zugangsdaten der Instanz.
6. Leeren und umstellen
Lassen Sie Consumer die Azure-Queues leeren, richten Sie Producer auf RabbitMQ und behalten Sie den Namespace, bis die letzte Nachricht verarbeitet ist. Das ist gängige Praxis, kein Schritt, den der Lauf plant.
Ein Namespace mit Queues und einem Topic, umgesetzt
Eine kleine Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links die Azure-Eingabe, rechts der Ressourcenblock des STACKIT-Terraform, den die Engine geschrieben hat; die Review-Kommentare darüber in der Datei sind hier weggelassen.
resource "azurerm_servicebus_namespace" "orders" {
name = "sb-orders-gwc"
location = azurerm_resource_group.msg.location
resource_group_name = azurerm_resource_group.msg.name
sku = "Premium"
capacity = 1
premium_messaging_partitions = 1
}
resource "azurerm_servicebus_queue" "invoices" {
name = "invoices"
namespace_id = azurerm_servicebus_namespace.orders.id
max_delivery_count = 5
lock_duration = "PT1M"
requires_duplicate_detection = true
dead_lettering_on_message_expiration = true
default_message_ttl = "P7D"
}
resource "azurerm_servicebus_queue" "sessions" {
name = "fulfilment-sessions"
namespace_id = azurerm_servicebus_namespace.orders.id
requires_session = true
max_delivery_count = 10
}
resource "azurerm_servicebus_topic" "events" {
name = "order-events"
namespace_id = azurerm_servicebus_namespace.orders.id
default_message_ttl = "P1D"
}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)
}
}Eine Instanz für den ganzen Namespace
Die Queues und das Topic werden keine Terraform-Ressourcen. Der Namespace wird zu einer stackit_rabbitmq_instance; sku = Premium, Kapazität und Messaging-Partitionen stehen als nicht übernommen im Entwurf, und Planname und Version sind Variablen ohne Standardwert.
Die Zugriffsliste hat keinen Standard
Die Variable für die erlaubten CIDRs lehnt eine leere Liste ab, denn der STACKIT-Standardbereich lässt die Adressen aller STACKIT-Kunden zu, wie die Engine festhält.
Die Version braucht eine Prüfung
Der Variablentext hält fest, dass Servicekatalog und STACKIT-Lifecycle-Seite bei der angebotenen RabbitMQ-Version nicht übereinstimmen; deshalb gibt es keinen Standardwert. Bestätigen Sie sie vor jedem Anwenden für Ihre Region. Stand November 2026 nennt die Lifecycle-Seite 4.0 (veröffentlicht April 2025, Ende der Unterstützung noch offen), 3.13 (Ende September 2025) und 3.10 (Ende März 2025). Keine der für diesen Leitfaden geöffneten STACKIT-Seiten zu RabbitMQ nennt die Protokolle, die eine Instanz annimmt; testen Sie Ihren AMQP-0-9-1- oder AMQP-1.0-Client daher gegen eine echte Instanz.
Was der Entwurf als nicht übernommen ausweist
Die Zeilen, die die Engine über der Instanz für den Namespace, die beiden Queues und das Topic geschrieben hat, gefolgt von den beiden Funktionswarnungen, so wie die Datei sie enthält.
# NOT CARRIED (azurerm_servicebus_namespace.orders): capacity = 1, name = sb-orders-gwc, premium_messaging_partitions = 1, sku = Premium — configure its queues and topics as queues and exchanges in the RabbitMQ instance; none of the namespace's settings is generated.
# NOT CARRIED (azurerm_servicebus_queue.invoices): dead_lettering_on_message_expiration = true, default_message_ttl = P7D, lock_duration = PT1M, max_delivery_count = 5, name = invoices, namespace_id, requires_duplicate_detection = true — a setting of azurerm_servicebus_namespace.orders: configure its queues and topics as queues and exchanges in the RabbitMQ instance; none of the namespace's settings is generated.
# NOT CARRIED (azurerm_servicebus_queue.sessions): max_delivery_count = 10, name = fulfilment-sessions, namespace_id, requires_session = true — a setting of azurerm_servicebus_namespace.orders: configure its queues and topics as queues and exchanges in the RabbitMQ instance; none of the namespace's settings is generated.
# NOT CARRIED (azurerm_servicebus_topic.events): default_message_ttl = P1D, name = order-events, namespace_id — a setting of azurerm_servicebus_namespace.orders: configure its queues and topics as queues and exchanges in the RabbitMQ instance; none of the namespace's settings is generated.
# azurerm_servicebus_namespace.orders: WARNING sb-sessions: Queues use sessions (ordered, grouped processing); RabbitMQ has no session concept, so ordering per key needs consistent-hash exchanges or single-active consumers.
# azurerm_servicebus_namespace.orders: WARNING sb-duplicate-detection: Duplicate detection is enabled; RabbitMQ has no built-in deduplication, so consumers must be idempotent.Service-Bus-Funktionen und ihre RabbitMQ-Antworten
Aus dem Lauf und seinen Begründungen. Die rechte Spalte nennt, wer entscheidet.
| Service-Bus-Funktion | RabbitMQ-Ansatz | Entscheidung |
|---|---|---|
| Queue | Eine RabbitMQ-Queue, die Sie in der Instanz einrichten | Queue-Namen und Argumente, durch das Anwendungsteam |
| Topic mit Subscriptions | Ein Exchange mit je einer gebundenen Queue pro Abonnent | Exchange-Typ und Bindings |
| Dead-Lettering | Ein Dead-Letter-Exchange als Queue-Argument | Welche Queues einen brauchen |
| Nachrichtenlebensdauer, Zustelllimit | Queue-Argumente; für die Sperrdauer gibt es keine Entsprechung, am nächsten kommt ihr der Parameter consumer_timeout | Limit akzeptieren oder im Consumer nachbauen |
| Sessions | Kein Session-Konzept: Consistent-Hash-Exchanges oder Single-Active-Consumer | Reihenfolge-Design pro Schlüssel |
| Duplikaterkennung | Keine eingebaute Deduplizierung: Consumer müssen idempotent sein | Idempotenz in den Consumern |
| Filterregel einer Subscription | Von diesem Build nicht bewertet; ein Architekt bestimmt das Ziel | Binding-Keys, Header oder Filter im Consumer |
| Namespace-Stufe | Ein RabbitMQ-Plan; eine Dimensionierungsentscheidung | Plangröße, Version, Zugriffsliste |
Die Sessions-Queue und die Duplikaterkennung in der Beispieleingabe erzeugen die beiden obigen Warnungen; der Lauf lässt jede dieser Einstellungen für eine Person offen.
Eine Ressource, die dieser Build nicht bewertet
Für eine Subscription-Regel gibt es im Bewertungskatalog dieses Builds keinen Eintrag. Der Lauf erfasst sie als manuelle Einheit mit Konfidenz LOW und schreibt nichts dafür. Links die Eingabe, rechts die Felder der Bewertung, wie der Lauf sie geschrieben hat.
resource "azurerm_servicebus_subscription_rule" "shipping_only" {
name = "eu-only"
subscription_id = azurerm_servicebus_subscription.shipping.id
filter_type = "SqlFilter"
sql_filter = "region = 'EU'"
}{
"id": "azurerm_servicebus_subscription_rule.shipping_only",
"result": {
"class": "MANUAL_REVIEW",
"confidence": "LOW",
"reason": "azurerm_servicebus_subscription_rule is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type).",
"coverage": "UNKNOWN_SOURCE_TYPE"
}
}Sie braucht trotzdem einen Verantwortlichen
Die Datei der manuellen Schritte führt die Regel unter den Schritten ohne verantwortliche Rolle, weil die Bewertung der Einheit keine Kategorie zuweist. Weisen Sie selbst eine Rolle zu.
Den Filter lesen, nicht nur den Namen
Der SQL-Filter bestimmt, welche Nachrichten eine Subscription erhält. Auf RabbitMQ wandert diese Logik in Bindings oder in den Consumer.
Entscheidungen, die bei Ihren Architekten liegen
Plan, Version und Zugriffsliste
Der Lauf fragt nach einem RabbitMQ-Plan, einer Version und den Client-CIDRs. Keiner hat einen Standardwert.
Reihenfolge und Duplikate
Verlangt eine Queue Sessions oder Duplikaterkennung, ändert sich das Anwendungsdesign. Entscheiden Sie das, bevor die erste Nachricht umzieht.
Nachrichten im Umlauf
Die Datei zum Datenumzug dieses Laufs ist als nicht anwendbar markiert: Die Quelle enthält keine Datenbank, keinen Cache und keinen Objektspeicher, und ein Queue- oder Topic-Dienst gilt nicht als zustandsbehaftet. Nachrichten, die noch in den Queues liegen, arbeiten Sie selbst ab.
Backups und Wiederherstellung
STACKIT dokumentiert automatische Backups des RabbitMQ-Dienstes: ein vollständiges Backup alle 4 Stunden, aufbewahrt für 14 Tage. Prüfen Sie, ob das zu Ihren Wiederherstellungsanforderungen passt.
Plugins, die Sie brauchen könnten
Die Dokumentation nennt Plugins, die Sie über die Parameterdatei aktivieren, darunter Consistent Hash Exchange, Shovel und Federation.
Fragen zu dieser Migration
Kann dieselbe Clientbibliothek mit beiden Brokern sprechen?
Nicht das Service-Bus-SDK in seiner jetzigen Form. Microsoft nennt AMQP 1.0 das primäre Protokoll von Service Bus und schreibt, dass sich damit Anwendungen bauen lassen, die mit Service Bus und mit Brokern wie RabbitMQ arbeiten. Der Lauf plant den Wechsel zu einem AMQP-0-9-1-Client. Welcher Weg trägt, hängt von der in Ihrer Region angebotenen RabbitMQ-Version und den Service-Bus-Funktionen ab, die Ihr Code nutzt; testen Sie ihn gegen die Instanz.
Legt StackToIT die Queues und Exchanges an?
Nein. Der Entwurf legt eine RabbitMQ-Instanz an. Queues und Exchanges richten Sie darin selbst ein, und jeder Queue-Name samt Einstellung erscheint als Hinweis „nicht übernommen“.
Wie ersetze ich Sessions?
RabbitMQ kennt kein Session-Konzept. Der Lauf verweist auf Consistent-Hash-Exchanges oder Single-Active-Consumer für die Reihenfolge pro Schlüssel; beides erfordert eine Designentscheidung.
Was passiert mit den Nachrichten in den Queues?
Das Werkzeug überträgt keine Daten. Leeren Sie die Azure-Queues mit den bestehenden Consumern oder veröffentlichen Sie gezielt neu, und behalten Sie den Namespace, bis die letzte Nachricht verarbeitet ist.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.