Rabbitmq

Message broker for queues over AMQP, MQTT and STOMP, with its management UI

RabbitMQ on Cubeship

RabbitMQ is a message broker: apps publish messages to queues and other apps consume them, over AMQP, MQTT or STOMP.

This template installs it on a Cubeship instance, with its management UI on a domain and its queues kept in a volume.

What it creates

rabbitmq — RabbitMQ with the management plugin, from rabbitmq:4.3.5-management. The management UI answers on the domain you choose; queues, users and definitions are kept in a volume at /var/lib/rabbitmq.

It needs Cubeship 0.7.0 or newer.

What you are asked

Input	What to give
Where the management UI answers	A domain you control, pointed at your instance.
The username apps and the UI sign in with	Anything; `admin` unless you change it.
That user's password	Nothing — the instance generates it and shows it once. Keep a copy.

Connecting an app

AMQP is not on the domain: the domain carries HTTP only. An app on the same instance connects at RabbitMQ's internal address, shown on its page in the dashboard. Installed with the suggested names, that is:

amqp://<username>:<password>@cubeship-rabbitmq-production-rabbitmq:5672

Nothing outside the instance can reach AMQP.

After installing

Open the domain and sign in with the username and the generated password.
Create a user per app under Admin → Users, rather than sharing this one.

The username and password only create the first user. Changing the variables afterwards changes nothing.

The volume

The broker runs as one copy on the machine its volume is on, and a deploy stops it for a few seconds: clients reconnect. Messages in durable queues survive it; messages in transient queues do not. Back the volume up from the app's settings.

Resources

The app is limited to 1 CPU and 1 GiB of memory, and RabbitMQ stops accepting messages when it nears that limit. Raise limits in template.yaml for long queues.

What this creates

rabbitmq

rabbitmq:4.3.5-management

/var/lib/rabbitmq

Volume of rabbitmq

template.yaml

# yaml-language-server: $schema=https://cubeship.dev/schema/template/v1.json
version: 1
# The first release that gives a volume to the user its image runs as.
minCubeship: "0.7.0"
project: rabbitmq

inputs:
  - key: domain
    type: domain
    label: Where the management UI answers
  - key: username
    type: text
    label: The username apps and the UI sign in with
    default: admin
  - key: password
    type: secret
    label: That user's password
    generate: 24

apps:
  - key: broker
    name: rabbitmq
    image: rabbitmq
    tag: "4.3.5-management"
    # The management UI, which is what the domain and the health check
    # reach. Apps connect over AMQP on 5672 at the internal address.
    port: 15672
    health: /
    domains:
      - host: ${input.domain}
    volumes:
      - path: /var/lib/rabbitmq
    limits: { cpu: 1, memory: 1Gi }
    env:
      # RabbitMQ keeps its data under its node name, which defaults to the
      # container's hostname — new on every deploy, so the queues would
      # seem to vanish. A fixed name keeps them.
      RABBITMQ_NODENAME: rabbit@localhost
      RABBITMQ_DEFAULT_USER: ${input.username}
      RABBITMQ_DEFAULT_PASS: ${input.password}