Deployment guide

Apache RocketMQ

Overview

Apache RocketMQ is an open-source distributed messaging and streaming platform built for low latency, high throughput and financial-grade reliability. It powers asynchronous decoupling, event streaming and transactional messaging across microservices.

The SecureAnyCloud image installs RocketMQ 5.3.3 under /opt/rocketmq and runs it in a single-node topology as a dedicated rocketmq system user under OpenJDK 17. The topology is one NameServer (the routing registry) and one Broker (the message store and serve engine), plus the RocketMQ Dashboard (a Spring Boot web UI) fronted by nginx on TCP 80 with HTTP Basic auth. The message store lives on a dedicated Azure data disk, and a unique Dashboard password is generated on the first boot of every VM. Backed by 24/7 SecureAnyCloud support.

What you get:

Apache RocketMQ 5.3.3 (NameServer + Broker) under /opt/rocketmq, run as the rocketmq system user.
OpenJDK 17 (headless), with the broker and nameserver JVM heaps tuned to fit the recommended VM size.
The RocketMQ Dashboard web UI, fronted by nginx on :80.
nginx HTTP Basic auth (the Dashboard has no public-facing auth) with a per-VM password in a root-only file.
A dedicated Azure data disk at /var/lib/rocketmq holding the message store. It is separate from the OS disk and re-provisioned with every VM.
rocketmq-namesrv.service, rocketmq-broker.service, rocketmq-dashboard.service and nginx.service as systemd units, enabled and active.
24/7 SecureAnyCloud support.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet and subnet in the target region.
Standard_B4ms (4 vCPU / 16 GiB RAM) as a good starting point. Scale up for higher message throughput.
An NSG that allows inbound 22/tcp from your management network and 80/tcp for the Dashboard.
To connect remote producers and consumers, also allow 9876/tcp (NameServer) and 10911/tcp (Broker). Front public exposure with TLS and IP allow-lists.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Apache RocketMQ by SecureAnyCloud, and select Create.

On Basics, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80). Review the dedicated data disk on the Disks tab, then choose Review + create and Create.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms once, then create the VM and open port 80. Replace the values in angle brackets:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:apache-rocketmq-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name rocketmq \
  --image sac1647283583153:apache-rocketmq-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name rocketmq --port 80 --priority 1010

Step 3 - Connect to your VM

Connect over SSH:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

Check that all four services are active:

systemctl is-active rocketmq-namesrv.service rocketmq-broker.service rocketmq-dashboard.service nginx.service

All four services report active. The NameServer starts in seconds. The Broker takes a little longer because it initializes its commit log on first boot.

Step 5 - Retrieve your Dashboard password

The Dashboard password is generated uniquely on the first boot of your VM and written to a root-only file. Read it:

sudo cat /root/apache-rocketmq-credentials.txt

This file contains ROCKETMQ_DASHBOARD_USER (admin) and ROCKETMQ_DASHBOARD_PASSWORD, plus the Dashboard URL and the NameServer/Broker addresses. Store the password somewhere safe.

Step 6 - Check the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes. Request it:

curl -s http://localhost/health

It returns ok. The endpoint is exempt from the Basic auth, so probes do not need credentials.

Step 7 - Open the web Dashboard

Browse to http://<vm-public-ip>/ and sign in as admin with the password from Step 5. The Dashboard's Cluster view shows the broker, its address, version (V5_3_3) and live produce/consume counters.

The Consumer view manages consumer (subscription) groups. You can filter by NORMAL, FIFO or SYSTEM and inspect each group's subscriptions and offsets.

The Message view searches messages on a topic by topic, message key, message ID or time range, and shows each message with full headers and body.

The OPS view manages the NameServer address list, the VIP-channel flag and TLS for the Dashboard's own admin client.

Step 8 - Send and receive a message from the command line

RocketMQ ships a tools.sh launcher with built-in quickstart producer and consumer classes. Point them at the local NameServer and send a batch of messages:

sudo -u rocketmq env NAMESRV_ADDR=127.0.0.1:9876 ROCKETMQ_HOME=/opt/rocketmq \
  /opt/rocketmq/bin/tools.sh org.apache.rocketmq.example.quickstart.Producer

Each send prints a SendResult line with sendStatus=SEND_OK and a msgId.

Now consume the messages back. The quickstart consumer is a long-running listener, so this example wraps it in timeout to pull for 20 seconds and then exit cleanly:

sudo -u rocketmq env NAMESRV_ADDR=127.0.0.1:9876 ROCKETMQ_HOME=/opt/rocketmq \
  timeout 20 /opt/rocketmq/bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer

The consumer prints Receive New Messages lines as it pulls the messages you just produced. Run it without timeout to keep listening, and press Ctrl-C to stop. This round trip proves the NameServer, Broker and store are all healthy.

Step 9 - Inspect the cluster with mqadmin

The mqadmin CLI talks to the NameServer and reports broker registration, topics and consumer groups. Run it:

sudo -u rocketmq env ROCKETMQ_HOME=/opt/rocketmq \
  /opt/rocketmq/bin/mqadmin clusterList -n 127.0.0.1:9876

You see the DefaultCluster with broker-a registered, its address, version and queue counts. List topics with topicList -n 127.0.0.1:9876.

Step 10 - Connect remote producers and consumers

The NameServer listens on 9876/tcp and the Broker on 10911/tcp, both bound to the VM's IP. To let external applications publish and subscribe, open those ports in your NSG and restrict the source to your application subnet:

az vm open-port --resource-group <your-rg> --name rocketmq --port 9876 --priority 1020
az vm open-port --resource-group <your-rg> --name rocketmq --port 10911 --priority 1030

Point your client's NAMESRV_ADDR (or rocketmq.namesrv.addr) at <vm-public-ip>:9876. The broker advertises itself to clients using brokerIP1, which this image sets to the VM's public IP automatically on first boot, so clients are redirected to a reachable broker address.

Step 11 - Confirm data lives on the dedicated disk

The message store is held on the dedicated Azure data disk, so it survives OS changes and can be resized independently. Check the mount:

findmnt /var/lib/rocketmq

The mount is backed by a separate Azure data disk captured into the image and re-provisioned on every VM. The commit log and consume queues live under /var/lib/rocketmq/store.

Enabling HTTPS

The nginx reverse proxy terminates plain HTTP on port 80 for the Dashboard. For public exposure, put a certificate in front of it.

The simplest option is to add a DNS name for the VM and use the companion SecureAnyCloud nginx-ssl-certbot image as a TLS reverse proxy. Alternatively, install certbot and extend the existing nginx site with a listen 443 ssl; server block and your certificate paths. Keep the Dashboard itself bound to loopback so the only public web surface is the authenticated, TLS-terminated proxy.

Maintenance

Configuration: the broker settings (store path, brokerIP1, cluster name, auto-create flags) are in /opt/rocketmq/conf/broker-sac.conf. Edit the file and run sudo systemctl restart rocketmq-broker to apply changes.
JVM heap: the broker and nameserver heaps are tuned in /opt/rocketmq/bin/runbroker.sh and runserver.sh. Increase them if you scale the VM up.
Backups: snapshot the /var/lib/rocketmq data disk to capture the message store.
Upgrades: replace the contents of /opt/rocketmq with a newer release (preserving conf/broker-sac.conf) and restart the services.
Security patches: unattended-upgrades remains enabled, so the OS continues to receive security updates automatically.

Support

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.

Apache RocketMQ and the RocketMQ logo are trademarks of the Apache Software Foundation. This image is produced by SecureAnyCloud and is not affiliated with or endorsed by the Apache Software Foundation. Apache RocketMQ is distributed under the Apache License 2.0.

Deploy on Azure

Launch Apache RocketMQ on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

The SecureAnyCloud image installs RocketMQ 5.3.3 under /opt/rocketmq and runs it in a single-node topology as a dedicated rocketmq system user under OpenJDK 17. The topology is one NameServer (the routing registry) and one Broker (the message store and serve engine), plus the RocketMQ Dashboard (a Spring Boot web UI) fronted by nginx on TCP 80 with HTTP Basic auth. The message store lives on a dedicated EBS data volume, and a unique Dashboard password is generated on the first boot of every instance. Backed by 24/7 SecureAnyCloud support.

What you get:

Apache RocketMQ 5.3.3 (NameServer + Broker) under /opt/rocketmq, run as the rocketmq system user.
OpenJDK 17 (headless), with the broker and nameserver JVM heaps tuned to fit the recommended instance size.
The RocketMQ Dashboard web UI, fronted by nginx on :80.
nginx HTTP Basic auth (the Dashboard has no public-facing auth) with a per-instance password in a root-only file.
A dedicated EBS data volume at /var/lib/rocketmq holding the message store. It is separate from the OS disk and re-provisioned with every instance.
rocketmq-namesrv.service, rocketmq-broker.service, rocketmq-dashboard.service and nginx.service as systemd units, enabled and active.
24/7 SecureAnyCloud support.

Prerequisites

Before you deploy this image, you need:

An AWS account where you can launch EC2 instances and subscribe to AWS Marketplace products.
An EC2 key pair in the target Region for SSH access.
A VPC and subnet, with a security group allowing inbound 22/tcp from your management network and 80/tcp for the Dashboard. To connect remote producers and consumers, also allow 9876/tcp (NameServer) and 10911/tcp (Broker) from the networks your clients use.
The AWS CLI (version 2) installed locally if you plan to deploy from the command line.

m5.large (2 vCPU / 8 GiB RAM) is a good starting point. Scale up for higher message throughput.

Connecting to your instance

SSH in as the default login user for the OS variant you launched. The SecureAnyCloud RocketMQ listing currently ships one variant:

OS variant AMI login user Notes

Ubuntu 24.04 LTS ubuntu Services: rocketmq-namesrv, rocketmq-broker, rocketmq-dashboard, nginx

ssh ubuntu@<instance-public-ip>

Launch the instance from the AWS Marketplace

Sign in to the AWS Marketplace, search for Apache RocketMQ by SecureAnyCloud, and choose Continue to Subscribe. Then choose Continue to Configuration and Continue to Launch.

Pick your Region, the recommended instance type, your VPC and subnet, and a security group that allows inbound 22 and 80 (and 9876 + 10911 if remote clients will connect). Select your EC2 key pair and launch.

Launch from the AWS CLI

Launch the instance with the AWS CLI and replace the values in angle brackets:

aws ec2 run-instances \
  --image-id <ami-id-from-marketplace> \
  --instance-type m5.large \
  --key-name <your-key-pair> \
  --security-group-ids <your-sg-id> \
  --subnet-id <your-subnet-id> \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=rocketmq}]'

The <ami-id-from-marketplace> is shown on the listing's launch page for your Region after you subscribe.

Confirm the services are running

Check that all four services are active:

systemctl is-active rocketmq-namesrv.service rocketmq-broker.service rocketmq-dashboard.service nginx.service

All four services report active. The NameServer starts in seconds. The Broker takes a little longer because it initializes its commit log on first boot.

Retrieve your Dashboard password

The Dashboard password is generated uniquely on the first boot of your instance and written to a root-only file. Read it:

sudo cat /root/apache-rocketmq-credentials.txt

This file contains ROCKETMQ_DASHBOARD_USER (admin) and ROCKETMQ_DASHBOARD_PASSWORD, plus the Dashboard URL and the NameServer/Broker addresses. Store the password somewhere safe.

Check the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes. Request it:

curl -s http://localhost/health

It returns ok and is exempt from the Basic auth, so probes do not need credentials. The Dashboard itself returns 401 without credentials and 200 with the admin password. Check the Dashboard status code:

curl -s -o /dev/null -w '%{http_code}\n' http://localhost/

Open the web Dashboard

Browse to http://<instance-public-ip>/ and sign in as admin with the password from Step 4. The Dashboard view shows the broker overview and live message throughput.

The Cluster view shows the broker, its address, version (V5_3_3) and produce/consume counters.

The OPS view manages the NameServer address list, the VIP-channel flag and TLS for the Dashboard's own admin client.

Send and receive a message from the command line

RocketMQ ships a tools.sh launcher with built-in quickstart producer and consumer classes. Point them at the local NameServer and send a batch of messages:

sudo -u rocketmq env NAMESRV_ADDR=127.0.0.1:9876 ROCKETMQ_HOME=/opt/rocketmq \
  /opt/rocketmq/bin/tools.sh org.apache.rocketmq.example.quickstart.Producer 2>&1 | grep SEND_OK | tail -3

Each send prints a SendResult line with sendStatus=SEND_OK and a msgId.

Now consume the messages back. The quickstart consumer is a long-running listener, so this example wraps it in timeout to pull for 20 seconds and then exit cleanly:

OUT=$(sudo -u rocketmq env NAMESRV_ADDR=127.0.0.1:9876 ROCKETMQ_HOME=/opt/rocketmq \
  timeout 20 /opt/rocketmq/bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer 2>&1 || true)
echo "$OUT" | grep 'Receive New Messages' | tail -3

Inspect the cluster with mqadmin

The mqadmin CLI talks to the NameServer and reports broker registration, topics and consumer groups. Run it:

sudo -u rocketmq env ROCKETMQ_HOME=/opt/rocketmq \
  /opt/rocketmq/bin/mqadmin clusterList -n 127.0.0.1:9876 2>/dev/null

You see the DefaultCluster with broker-a registered, its address, version and queue counts. List topics with topicList -n 127.0.0.1:9876.

Connect remote producers and consumers

The NameServer listens on 9876/tcp and the Broker on 10911/tcp. To let external applications publish and subscribe, open those ports in your security group and restrict the source to your application subnet:

aws ec2 authorize-security-group-ingress --group-id <your-sg-id> \
  --protocol tcp --port 9876 --cidr <your-app-subnet-cidr>
aws ec2 authorize-security-group-ingress --group-id <your-sg-id> \
  --protocol tcp --port 10911 --cidr <your-app-subnet-cidr>

Point your client's NAMESRV_ADDR (or rocketmq.namesrv.addr) at <instance-address>:9876. The broker advertises itself to clients using brokerIP1, which this image sets to the instance's private IP automatically on first boot. That address is directly reachable by RocketMQ clients running in the same VPC, which is the normal deployment.

For clients outside the VPC, reach the instance over its private address via VPC peering or a VPN. Alternatively, edit brokerIP1 in /opt/rocketmq/conf/broker-sac.conf to an address your clients can route to, then run sudo systemctl restart rocketmq-broker.

Confirm data lives on the dedicated volume

The message store is held on the dedicated EBS data volume, so it survives OS changes and can be resized independently. Check the mount:

findmnt /var/lib/rocketmq

The mount is backed by a separate EBS volume captured into the AMI and re-provisioned on every instance. The commit log and consume queues live under /var/lib/rocketmq/store.

Enabling HTTPS

The nginx reverse proxy terminates plain HTTP on port 80 for the Dashboard. For public exposure, put a certificate in front of it.

The simplest option is to add a DNS name for the instance and use the companion SecureAnyCloud nginx-ssl-certbot image as a TLS reverse proxy. Alternatively, install certbot and extend the existing nginx site with a listen 443 ssl; server block and your certificate paths. Keep the Dashboard itself bound to loopback so the only public web surface is the authenticated, TLS-terminated proxy.