BlazingMQ on Ubuntu 24.04 on Azure User Guide

Overview

BlazingMQ is an open source distributed message queueing framework from Bloomberg. Its high performance C++ broker, bmqbrkr, gives applications durable, ordered queues with priority, fanout and broadcast delivery semantics, and the bundled bmqtool client publishes and consumes messages from the command line.

The cloudimg image builds BlazingMQ from pinned upstream sources and installs the broker at /usr/local/bin/bmqbrkr and the client at /usr/local/bin/bmqtool, running as the blazingmq service. The broker listens on TCP 30114, with file backed storage at /var/lib/blazingmq/storage on the OS disk and configuration under /etc/blazingmq.

Why this image saves you real work: BlazingMQ publishes no prebuilt binary. There are no release binaries, no public container image and no distribution package, so running it normally means compiling the broker together with the BDE and NTF libraries, a build that takes hours. This image ships it already built.

Secure by default, no default login: the stock broker listens on every interface and lets anonymous clients straight through, which is unacceptable to publish. This image pins both controls. The TCP listener is bound to 127.0.0.1 only, so the broker is not reachable from the network at all, and authentication is required with anonymousCredential.disallow set, so an unauthenticated client is rejected at session negotiation. A blazingmq-firstboot.service oneshot generates a unique username and password on each VM's first boot, renders the broker configuration with it, writes the credential to a root only file, then disables itself. No two VMs share a credential and none is baked into the image.

Fail secure: the broker carries a bootstrap gate (ConditionPathExists=/var/lib/blazingmq/.bootstrap-ready) that only clears after first boot has rendered the configuration with the per VM credential, so the broker cannot start at all until a credential exists. If first boot were interrupted, the broker simply would not start, rather than coming up open.

Note on the interface: BlazingMQ is a broker with no web UI. You drive it with bmqtool from the command line, or from your own application through the BlazingMQ C++, Java or Python client libraries. This guide uses bmqtool.

What is included:

• BlazingMQ (verified at 0.95.14) built from pinned upstream sources, Apache-2.0
• blazingmq.service running the bmqbrkr broker on 127.0.0.1:30114
• bmqtool command line producer and consumer client
• BASIC authentication required, anonymous clients rejected
• blazingmq-firstboot.service for the per VM credential and broker configuration
• A unique per VM username and password generated on first boot, in a root only 0600 file
• A fail secure bootstrap gate so the broker never starts without a credential
• Upstream's single node cluster definition and seven ready to use bmq.test.* queue domains
• File backed persistent storage at /var/lib/blazingmq/storage
• Ubuntu 24.04 LTS base, fully patched
• 24/7 cloudimg support, 24h response SLA

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet with a subnet. The broker is CPU and memory light for evaluation but throughput scales with both. Recommended VM size: Standard_B2s (2 vCPU, 4 GB RAM) for evaluation and development, or a Standard_D4s_v5 or larger for production message rates. Storage is file backed on the OS disk, so expand the disk before persisting large queue backlogs.

Because the broker is bound to loopback, the only inbound port you need to open is TCP 22 for SSH.

Step 1: Deploy from the Azure Portal

Search the Marketplace for BlazingMQ on Ubuntu 24.04, choose your VM size, and attach an NSG that allows TCP 22 (SSH) from your management network. Do not open TCP 30114: the broker is deliberately bound to loopback and is reached over an SSH tunnel or from an application running on the same VM.

Step 2: Deploy from the Azure CLI

RG="blazingmq-prod"; LOCATION="eastus"; VM_NAME="blazingmq-01"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/blazingmq-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az network vnet create -g "$RG" --name bmq-vnet --address-prefix 10.92.0.0/16 --subnet-name bmq-subnet --subnet-prefix 10.92.1.0/24
az network nsg create -g "$RG" --name bmq-nsg
az network nsg rule create -g "$RG" --nsg-name bmq-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp
az vm create -g "$RG" --name "$VM_NAME" --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name bmq-vnet --subnet bmq-subnet --nsg bmq-nsg --public-ip-sku Standard

Step 3: Connect via SSH

ssh azureuser@<vm-ip>

Step 4: Verify the broker and its listener

The broker runs as blazingmq.service and listens on TCP 30114. Confirm the service is active and, critically, that the socket is bound to 127.0.0.1 and not to every interface.

sudo systemctl is-active blazingmq
ss -tln | grep 30114
# bmqtool prints its usage and exits 1 by convention, so tolerate that exit status here
sudo /usr/local/bin/bmqtool --help 2>&1 | head -3 || true

active
LISTEN 0      4096       127.0.0.1:30114      0.0.0.0:*
Usage: /usr/local/bin/bmqtool [--mode <mode>] [-b|broker <address>]

You should see the service active and the listening socket bound to 127.0.0.1:30114. A bind address of 0.0.0.0:30114 would mean the broker was reachable from the network, which this image never ships.

Step 5: Read your per VM broker credentials

The username and password were generated on this VM's first boot and stored in a root only file. Read them and confirm the file's ownership and mode.

sudo cat /root/blazingmq-credentials.txt
sudo stat -c '%a %U:%G' /root/blazingmq-credentials.txt

The file holds BMQ_USER, BMQ_PASSWORD and BMQ_BROKER_URI, and is owned root:root with mode 600. These credentials exist only on this VM; no other deployment of this image shares them.

Step 6: Publish and consume your first message

This is the full round trip: publish a message to a queue with an authenticated producer, then consume it back with an authenticated consumer and confirm the payload matches. BlazingMQ addresses queues as bmq://<domain>/<queue-name>, and the image ships upstream's bmq.test.persistent.priority domain ready to use.

U=$(sudo grep '^BMQ_USER=' /root/blazingmq-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^BMQ_PASSWORD=' /root/blazingmq-credentials.txt | cut -d= -f2-)
QUEUE="bmq://bmq.test.persistent.priority/hello"
sudo /usr/local/bin/bmqtool --mode auto --broker tcp://localhost:30114 \
  --queueuri "$QUEUE" --queueflags write,ack \
  --eventscount 1 --eventsize 1 --messagepattern "hello-cloudimg" \
  --shutdownGrace 3 --authnMechanism BASIC --authnData "$U:$P" 2>&1 | tail -5

The producer ends with its summary line, confirming one message was accepted by the broker:

Final stats: produced 1 messages [9  B] in 1 events [68  B] (Protocol: 86.76%)

Now consume it back. The --dumpmsg flag prints the payload and --confirmmsg acknowledges it so the broker can release it.

U=$(sudo grep '^BMQ_USER=' /root/blazingmq-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^BMQ_PASSWORD=' /root/blazingmq-credentials.txt | cut -d= -f2-)
QUEUE="bmq://bmq.test.persistent.priority/hello"
sudo /usr/local/bin/bmqtool --mode auto --broker tcp://localhost:30114 \
  --queueuri "$QUEUE" --queueflags read --dumpmsg --confirmmsg \
  --shutdownGrace 8 --authnMechanism BASIC --authnData "$U:$P" 2>&1 | tail -12

The consumer prints the message it received as a hex dump with the decoded ASCII on the right:

PUSH #0: [ type = PUSH queue = [ uri = bmq://bmq.test.persistent.priority/hello ... ] ]
     0:   68656C6C 6F2D636C 6F756469 6D673030     |hello-cloudimg00|
    16:   30303030 303030                         |0000000         |

The hello-cloudimg payload the producer published is there, zero padded to the message size. That is a complete publish, queue and consume cycle through the broker. Note that --dumpmsg wraps the ASCII column every 16 bytes, so a longer payload is shown across several rows.

Step 7: Confirm authentication is enforced

Run the same producer with no credentials. The broker refuses the session, which is what keeps the queue closed to anything that cannot authenticate.

sudo timeout -k 5 20 /usr/local/bin/bmqtool --mode auto --broker tcp://localhost:30114 \
  --queueuri "bmq://bmq.test.persistent.priority/hello" --queueflags write,ack \
  --eventscount 1 --shutdownGrace 3 > /tmp/bmq-anon.log 2>&1 || true
tail -6 /tmp/bmq-anon.log

timeout -k 5 20 is important here: a rejected client keeps retrying the connection indefinitely rather than exiting, and it does not stop on a plain TERM, so without the -k (force kill) the command never returns. Redirecting to a file rather than piping to tail matters for the same reason: a client child process can keep the pipe open after the timeout fires, leaving tail waiting forever.

The client never opens the queue. The broker states the refusal explicitly in its own log, which is the authoritative proof that authentication is enforced:

sudo journalctl -u blazingmq --no-pager | grep -o "Anonymous credential is disallowed[^']*" | tail -2

Anonymous credential is disallowed, cannot negotiate without authentication.
Anonymous credential is disallowed, cannot negotiate without authentication.

Combined with the loopback bind, an attacker needs both host access and the per VM credential.

Step 8: Reach the broker from your workstation

Because the broker is loopback only, connect to it through an SSH tunnel from your own machine. Run this on your workstation, not on the VM:

ssh -L 30114:127.0.0.1:30114 azureuser@<vm-ip>

With the tunnel open, any BlazingMQ client on your workstation can point at tcp://localhost:30114 and authenticate with the per VM credential, exactly as if it were local. This keeps the broker off the public internet while still making it usable from anywhere you can SSH.

For an application deployed on the same VM, no tunnel is needed: connect directly to tcp://localhost:30114.

Step 9: Queue domains and delivery modes

A BlazingMQ domain defines the storage and delivery behaviour for the queues inside it. The image ships upstream's seven test domains, covering each delivery mode:

ls /etc/blazingmq/domains/

bmq.test.mem.broadcast.json        bmq.test.persistent.fanout.sc.json
bmq.test.mem.fanout.json           bmq.test.persistent.priority.json
bmq.test.mem.priority.json         bmq.test.persistent.priority.sc.json
bmq.test.persistent.fanout.json

• bmq.test.persistent.priority and bmq.test.mem.priority: priority mode, where each message goes to exactly one of the connected consumers, the classic work queue.
• bmq.test.persistent.fanout and bmq.test.mem.fanout: fanout mode, where every named application gets its own copy of every message.
• bmq.test.mem.broadcast: broadcast mode, where messages go to all currently connected consumers and are not retained for absent ones.
• The .sc variants use strong consistency rather than eventual consistency.

Domains beginning bmq.test.persistent are file backed, so their messages survive a broker restart; bmq.test.mem domains are memory backed and are not retained across a restart. To add your own domain, copy one of these files, rename it to your domain name, adjust the limits, and restart the broker with sudo systemctl restart blazingmq.

Persistence, first boot and updates

Queue storage is file backed at /var/lib/blazingmq/storage on the OS disk, so persistent queues survive both a broker restart and a VM reboot. Back up that directory, or snapshot the disk, to protect queued messages.

blazingmq-firstboot.service runs once on the first boot of each VM. It generates the per VM credential, renders /etc/blazingmq/bmqbrkrcfg.json with it, writes /root/blazingmq-credentials.txt and the MOTD, raises the bootstrap marker that unblocks the broker, then disables itself. It never runs again, so your credential is stable for the life of the VM.

To rotate the credential later, edit the authentication.authenticators[0].settings entry in /etc/blazingmq/bmqbrkrcfg.json, update /root/blazingmq-credentials.txt to match, and restart the broker.

The Ubuntu base keeps receiving unattended security updates. To move to a newer BlazingMQ release, rebuild from upstream sources or launch a newer cloudimg image version.

Support

Every cloudimg image includes 24/7 support with a 24 hour response SLA. Contact support@cloudimg.co.uk with your VM's region and image version.

The full BlazingMQ documentation is at bloomberg.github.io/blazingmq.