This article describes how to migrate an existing service using RabbitMQ external server to Kubernetes using KubeMQ while preserving the ability to communicate with other legacy services connected to the RabbitMQ server. For this purpose, we will use the KubeMQ Targets and Sources connectors to convert messages between RabbitMQ and KubeMQ as follows:

KubeMQ Sources connector will consume messages from RabbitMQ topic named “Ping”, then convert the messages to a KubeMQ events format and send the messages to events.rabbit.ping channel on the KubeMQ cluster.

KubeMQ targets connector subscribes to KubeMQ “Pong” channel events.rabbit.pong. It then converts the message to RabbitMQ format and publishes the messages to the Pong topic.

We will use 2 applications here. The first one is the ping application, which is the Legacy Service. The ping application sends ping messages to the RabbitMQ ping topic and consumes messages from the pong topic. The second application, which is the migrated to Kubernetes one, subscribes to the events.rabbit.ping channel and sends back pong responses to events.rabbit.pong channel.

Before building the integrations, you must deploy a KubeMQ cluster. This can be done by typing, “kubemqctl g c" from KubeMQ CTL console, we can see that we have already deployed the KubeMQ cluster on the KubeMQ namespace with 3 pods.

We will start by managing and adding the integration needed for the migration. After typing “kubemqctl m” command we will select “Manage KubeMQ Integrations”

Next, we will add 2 integrations. The first one is a source integration for connecting to a RabbitMQ server and forwarding all the messages to KubeMQ. The second one will be a target integration that will listen to messages that are coming from KubeMQ and send it to the RabbitMQ server.

To add the KubeMQ Source integration, follow this is the procedure:

1. Select “Source Integration”
2. Setting a unique name such as “rabbit.ping”.
3. Under “Source Kind," select “messaging.rabbitmq”.
4. Enter the connection string of the external RabbitMQ.
5. When prompted to set dynamic channel mapping, decline.
6. Set queue name as “ping”.
7. For Target Kind, select “kubemq.events”.
8. Set your channel mapping mode to “implicit," and when prompted to use 'events.rabbit.ping’ as the events channel, accept it.
9. When prompted to add middlewares, decline, and then save your settings.

To add the KubeMQ Target integration, follow this procedure:

1. Set your integration as “rabbit.pong”
2. Select your target kind as “messaging.rabbitmq”.
3. Your connection string is the same as the one you used previously.
4. For KubeMQ Source Kind, select “kubem.events”. This will allow you to receive replies coming from the pong application.
5. Set events channel as “evenrts.rabbit.pong”. When prompted to add middlewares, decline just like you did earlier.
6. Save all your settings.

Now you have two integrations: Source and Target. KubeMQ Source integration receives ping message from RabbitMQ, connects to RabbitMQ server, and converts them to events messages in KubeMQ. The KubeMQ Target integration listens to the events channel (events.rabbit.pong) and sends it to the RabbitMQ server.

After we have configured the Sources and Targets connectors we can now test the applications. The first one is the Legacy Service Ping, which is connected only to RabbitMQ, sending and receiving messages from topics in RabbitMQ.
The second one is the Migrated to Kubernetes application Pong, which is directly linked to the KubeMQ cluster. Run RabbitMQ Ping Sender App. It should immediately start connecting to RabbitMQ. However, no response should be received because the pong app is not yet live. Therefore, go ahead and run Pong Service App. You should now see that the pong is connecting directly to the KubeMQ cluster, and there is back and forth communication between the Ping and the Pong applications.

We have demonstrated how to Migrate RabbitMQ connected service from a legacy environment to Kubernetes by using KubeMQ platform components. This type of migrations can be easily configured by using KubeMQ CTL automatic connectors creation functionalities, saving developers, and DevOps team precious time and costs in their migration to Kubernetes journey.