cubeshipd/rabbitmq
RabbitMQ
RabbitMQ is a message broker: apps publish messages to queues and other apps consume them, over AMQP, MQTT or STOMP.
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, AMQP on a TCP port, 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.2 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. |
| The port AMQP answers on | 5672 by default. Choose a port from 1024 to 65535, and open it in your provider's firewall too. |
Connecting an app
AMQP is not on the domain: the domain carries HTTP only. From outside the instance, connect to the instance's address on the port you chose. From an app on the same instance, use 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
For an external client, the equivalent URL is
amqp://<username>:<password>@<your VPS address>:<chosen port>. AMQP has no
TLS configured here, so do not publish it to an untrusted network without
putting an authenticated, encrypted proxy in front of it.
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
TCP 5672
Published by rabbitmq on ${input.amqpPort}
# yaml-language-server: $schema=https://cubeship.dev/schema/template/v1.json
version: 1
name: 'RabbitMQ'
# The first release that publishes AMQP and gives a volume to the user its image runs as.
minCubeship: "0.7.2"
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
- key: amqpPort
type: number
label: The port AMQP answers on
help: Choose a port from 1024 to 65535, and open it in your provider's firewall too.
default: 5672
min: 1024
max: 65535
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}
tcp:
- port: 5672
host: ${input.amqpPort}
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}