ORACLE STREAMING UND QUEUE → STACKIT · LEITFADEN
OCI Streaming und Queue zu STACKIT
OCI Queue zieht auf STACKIT RabbitMQ um, OCI Streaming auf einen selbst betriebenen Kafka-kompatiblen Broker auf der STACKIT Kubernetes Engine (SKE), weil STACKIT keinen verwalteten Kafka-Dienst hat. StackToIT stuft Queues als REPLATFORM und Streams als CONTAINERIZE ein, lässt den Stream Pool bei Ihnen und nennt die SKE-Versionen, auf denen Sie landen können. Dieser Leitfaden folgt der Migration der Reihe nach und markiert, was der Lauf entscheidet und was bei Ihnen liegt.
Die Migration in sechs Schritten
Eine Demo-Umgebung mit fünf Ressourcen, bewertet am 4. November 2026, liefert die Reihenfolge. Die Schritte führt Ihr Team aus; der Lauf liefert Ziele, Klassen und Abhängigkeiten.
1. Queues, Streams und Clients erfassen
Führen Sie jeden Producer und Consumer mit dem Protokoll auf, das er verwendet. OCI Queue bietet eine REST-API und das STOMP-Protokoll; OCI Streaming ist mit den meisten Kafka-APIs kompatibel. Das Client-Protokoll bestimmt, wie viel Anwendungscode sich ändert.
2. Den Broker je Stream wählen
Streams landen auf einem selbst betriebenen Kafka-kompatiblen Broker auf SKE, oder das Messaging-Design wechselt zu RabbitMQ. Der Lauf hält die erste Option als Ziel fest; seine Begründung nennt die zweite als Alternative.
3. Den SKE-Cluster auf einer unterstützten Version bauen
Wählen Sie eine Kubernetes-Version, die der Bericht als geeignet markiert. Planen Sie den Broker mit Partitionszahl und Aufbewahrung der Quell-Streams, die der Lauf als Einstellungen führt, die bei Ihnen liegen.
4. RabbitMQ-Instanz und Queues anlegen
Aus jeder OCI-Queue wird eine Queue auf STACKIT RabbitMQ. Bilden Sie Aufbewahrung, erneute Zustellung und Dead-Letter-Verhalten mit RabbitMQ-Funktionen nach und testen Sie sie.
5. Producer und Consumer kontrolliert umstellen
Nachrichten, die noch unterwegs sind, werden vor der Umstellung abgearbeitet. Bei Streams vereinbaren Sie, wie Consumer ihre Position behalten und wie lange beide Seiten parallel laufen.
6. Die OCI-Seite nach der Haltefrist stilllegen
Behalten Sie OCI-Queues und -Streams, bis das Rollback-Fenster endet. Löschen Sie sie erst nach der vereinbarten Haltefrist (allgemeine Praxis).
Ein Stream und sein Pool, bewertet
Links der Pool und beide Streams in der Eingabe, rechts die Entscheidungen für den Pool und den Stream clicks, wie sie in assessment.json stehen; orders wird genauso bewertet. Die Streams sind zugeordnet; der Stream Pool steht nicht im Katalog dieses Builds und bleibt bei Ihren Architekten. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten.
resource "oci_streaming_stream_pool" "events" {
compartment_id = var.compartment_id
name = "events"
}
resource "oci_streaming_stream" "orders" {
name = "orders"
partitions = 6
retention_in_hours = 72
stream_pool_id = oci_streaming_stream_pool.events.id
}
resource "oci_streaming_stream" "clicks" {
name = "clicks"
partitions = 12
retention_in_hours = 24
stream_pool_id = oci_streaming_stream_pool.events.id
}[
{
"id": "oci_streaming_stream_pool.events",
"result": {
"class": "MANUAL_REVIEW",
"confidence": "LOW",
"reason": "oci_streaming_stream_pool 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)."
}
},
{
"id": "oci_streaming_stream.clicks",
"result": {
"class": "CONTAINERIZE",
"confidence": "MEDIUM",
"target": {
"service": "a self-managed Kafka-compatible broker on SKE"
},
"reason": "STACKIT has no managed Kafka service. The stream moves to a self-managed broker on SKE, or the messaging design changes to RabbitMQ."
}
}
]CONTAINERIZE, mittlere Konfidenz
Der Stream wird zu einem Workload, den Sie auf SKE betreiben. Der Bericht nennt einen selbst betriebenen Kafka-kompatiblen Broker, mit einem SKE-Cluster als STACKIT-Ressource dahinter.
Der Pool ist manuell
oci_streaming_stream_pool ist eine MANUAL_REVIEW-Einheit ohne Ziel. Oracle beschreibt einen Pool als Gruppierung von Streams mit gemeinsamen Kafka- oder Sicherheitseinstellungen; diese übernehmen Sie von Hand.
Partitionen und Aufbewahrung liegen bei Ihnen
name, partitions, retention_in_hours und stream_pool_id sind die vier kritischen Einstellungen, die der Bericht für den Stream führt. Die Demo setzt für clicks 12 Partitionen und 24 Stunden, für orders 6 und 72.
Zwei Queues, eine mit Dead-Lettering, bewertet
Die Queue jobs verschiebt eine Nachricht nach 5 Zustellversuchen in eine Dead Letter Queue; jobs_dead ist eine zweite, gewöhnliche Queue. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten. Die Demo setzt für jobs_dead 7 Tage (604800 Sekunden), die maximale Aufbewahrungsdauer, die Oracle für eine Queue dokumentiert.
resource "oci_queue_queue" "jobs_dead" {
compartment_id = var.compartment_id
display_name = "jobs-dead"
retention_in_seconds = 604800
}
resource "oci_queue_queue" "jobs" {
compartment_id = var.compartment_id
display_name = "jobs"
retention_in_seconds = 345600
visibility_in_seconds = 60
timeout_in_seconds = 20
dead_letter_queue_delivery_count = 5
}[
{
"id": "oci_queue_queue.jobs",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT RabbitMQ"
},
"reason": "An OCI queue becomes a queue on STACKIT RabbitMQ. Clients change protocol, and messages in flight are drained before cut-over."
}
},
{
"id": "oci_queue_queue.jobs_dead",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT RabbitMQ"
},
"reason": "An OCI queue becomes a queue on STACKIT RabbitMQ. Clients change protocol, and messages in flight are drained before cut-over."
}
}
]REPLATFORM zu RabbitMQ
Beide werden zu Queues auf einer STACKIT-RabbitMQ-Instanz. Laut Begründung wechseln die Clients das Protokoll, und Nachrichten, die noch unterwegs sind, werden vor der Umstellung abgearbeitet.
Verhaltenseinstellungen bleiben bei Ihnen
Aufbewahrung, Sichtbarkeits-Timeout, Polling-Timeout und die Zustellzahl bis zum Dead-Lettering sind als Einstellungen geführt, die Sie übernehmen. Der Lauf übersetzt sie nicht.
Die Dead-Letter-Verbindung beachten
In der Eingabe setzt jobs eine Zustellzahl von 5, doch nichts im Terraform der Demo verweist auf jobs_dead; die Paarung besteht nur im Namen. Legen Sie sie im RabbitMQ-Design ausdrücklich fest.
Wie die Messaging-Umgebung zugeordnet wird
| OCI-Ressource | STACKIT-Ziel | Migrationsklasse |
|---|---|---|
| OCI Queue (jobs, jobs_dead) | STACKIT-RabbitMQ-Instanz mit Queues | Replatforming |
| OCI Stream (orders, clicks) | Selbst betriebener Kafka-kompatibler Broker auf SKE; RabbitMQ, wenn sich das Design ändert | Containerisieren |
| Stream Pool (events) | Kein Ziel vorgeschlagen; gemeinsame Kafka- und Sicherheitseinstellungen von Hand übernehmen | Architekturentscheidung |
Klassen und Ziele, wie der Lauf sie entschieden hat. Queue-Paar und Stream-Paar sind je zwei Einheiten, hier je eine Zeile.
Die SKE-Versionen, auf denen Sie landen können
Der Bericht nennt jede SKE-Version mit ihren Daten, gelesen aus den STACKIT-Seiten am 3. November 2026 und nicht über den 1. Februar 2027 hinaus verbürgt. Das sind die Zeilen, wie sie in engineering/architect-report.md stehen.
| Version | State | Released | Deprecated | Expires | Production suitability | Upgrade action | Migration timing risk |
|---|---|---|---|---|---|---|---|
| 1.36 | SUPPORTED | 2026-08-27 | not stated | 2027-06-09 | SUITABLE | PLAN | LOW |
| 1.35 | UNKNOWN | not stated | not stated | 2027-02-10 | UNKNOWN | UNKNOWN | UNKNOWN |
| 1.34 | EXPIRED | 2025-12-16 | 2026-08-28 | 2026-10-14 | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |
| 1.33 | EXPIRED | 2025-07-29 | 2026-06-09 | 2026-06-10 (sources disagree: 2026-07-08) | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |
| 1.32 | EXPIRED | not stated | 2026-02-20 | 2026-04-15 | NOT_SUITABLE | MANDATORY_UPDATE_APPLIES | HIGH |Auf 1.36 landen
1.36 ist unterstützt, mit geplantem Upgrade und Ablauf am 9. Juni 2027. Die STACKIT-Lifecycle-Seite nennt denselben Ablauf.
1.35 ist nicht bewertet
Der Lauf führt sie als UNKNOWN und gibt an, es gebe keine Datumsbelege; daher ist sie nicht bewertet, obwohl ihre Zeile ein Ablaufdatum am 10. Februar 2027 zeigt, dasselbe Datum, das die STACKIT-Lifecycle-Seite nennt. So oder so endet sie vier Monate vor 1.36; landen Sie nicht darauf.
Abgelaufene Versionen sind keine Option
1.32, 1.33 und 1.34 sind abgelaufen; das verpflichtende Update greift. Ein selbst betriebener Broker auf SKE ist von jedem Cluster-Upgrade betroffen; planen Sie Broker- und Cluster-Upgrades gemeinsam.
Entscheidungen, die Ihre Architekten treffen
Kafka-kompatibler Broker oder RabbitMQ für Streams
Ein Stream behält Nachrichten nach dem Lesen und lässt Consumer innerhalb der Aufbewahrungszeit erneut lesen; die Reihenfolge gilt je Partition. Aus einer Queue verschwindet eine Nachricht, sobald der Consumer sie löscht. Lesen Ihre Consumer erneut, ist RabbitMQ ein Redesign und kein Austausch.
Wer den Broker betreibt
Einen Broker auf SKE dimensionieren, härten, aktualisieren und sichern Sie selbst. Nennen Sie im Plan die Rufbereitschaft und den Upgrade-Rhythmus.
Wie Queue-Semantik nachgebildet wird
OCI Queue kennt ein Sichtbarkeits-Timeout und eine maximale Zustellzahl; RabbitMQ stellt unbestätigte Nachrichten erneut zu und bietet Nachrichtenablauf und Dead-Letter-Exchanges (RabbitMQ-Funktionen, nicht STACKIT-Dokumentation: prüfen Sie sie für die gewählte Plan-Version).
Client-Protokoll
Die STACKIT-RabbitMQ-Seite nennt MQTT und STOMP als Plugins und führt AMQP dort nicht auf. Klären Sie vor dem Aufbau, welches Protokoll Ihre Clients sprechen.
Cutover-Reihenfolge und Replay-Fenster
Producer, Consumer und die Parallelphase entwerfen Sie; der Lauf liefert nur Abhängigkeitswellen (Queues und Pool in Welle 1, Streams in Welle 2).
Fragen aus Integrationsteams
Bietet STACKIT einen verwalteten Kafka-Dienst?
Der Lauf hält fest, dass STACKIT keinen verwalteten Kafka-Dienst hat. Deshalb sind Streams CONTAINERIZE, mit einem selbst betriebenen Broker auf SKE als Ziel.
Überträgt StackToIT die Nachrichten?
Nein. Die Datei zum Datenumzug führt für diese Umgebung den Zustand NOT APPLICABLE, weil Queue- und Topic-Dienste nicht als zustandsbehaftet gelesen werden. Nachrichten, die noch unterwegs sind, arbeitet Ihr Team vor der Umstellung ab.
Können wir vorhandene Kafka-Clients auf den neuen Broker richten?
OCI Streaming ist mit den meisten Kafka-APIs kompatibel; daher sind die Clients meist schon Kafka-Clients, und es ändern sich vor allem Endpunkt, Authentifizierung und Topic-Einstellungen. Prüfen Sie das mit Ihren Client-Versionen.
Was bleibt nach dem Lauf bei uns?
Alle fünf Einheiten sind manuelle Schritte: Der Lauf erzeugt 0 Einheiten, weil er für eine Oracle-Cloud-Quelle keine STACKIT-Ressourcenblöcke schreibt, und jede der vier zugeordneten Einheiten führt kritische Einstellungen, die kein Entwurf abdeckt; der Stream Pool wird gar nicht bewertet.
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.