Learn RabbitMQ - Docker & Kubernetes Deployment

#Introduction

Since episode 3 you've been running RabbitMQ in Docker with docker run. Now it's time to do it properly: configuration via environment variables, restart-surviving storage, multi-container clustering, and finally deployment to Kubernetes — where modern production RabbitMQ actually lives.

Kubernetes takes RabbitMQ to the next level: nodes are replicated via a StatefulSet, disk is stored in a PersistentVolume, and the official operator manages the cluster's entire lifecycle. Without proper setup, RabbitMQ on K8s can lose data — for example, when a container is restarted without a volume.

This episode builds the Docker foundation first, then raises it to Kubernetes with best practices: operators, headless services, probes, and safe update strategies.

#Docker Deployment

#Official Image and Environment Variables

Use the official image and configure it via environment variables:

docker run -d --name rabbitmq \
  -e RABBITMQ_DEFAULT_USER=arman \
  -e RABBITMQ_DEFAULT_PASS=Arman123 \
  -e RABBITMQ_DEFAULT_VHOST=/ \
  -p 5672:5672 -p 15672:15672 \
  rabbitmq:3.13-management

The RABBITMQ_DEFAULT_USER environment variable creates the default user automatically — replacing the need for a manual add_user script.

#Volumes for Persistence

Queue data and metadata must be stored in a volume, not in the container layer that disappears on restart:

docker run -d --name rabbitmq \
  -v rabbitmq_data:/var/lib/rabbitmq \
  -p 5672:5672 -p 15672:15672 \
  rabbitmq:3.13-management

The rabbitmq_data volume ensures messages and metadata survive docker restart and container replacement.

#Docker Compose Clustering

Compose makes it easy to run a multi-node cluster on one host:

services:
  rabbitmq1:
    image: rabbitmq:3.13-management
    hostname: rabbitmq1
    environment:
      - RABBITMQ_ERLANG_COOKIE=rahasiaCookie
    volumes:
      - rabbitmq1_data:/var/lib/rabbitmq
  rabbitmq2:
    image: rabbitmq:3.13-management
    hostname: rabbitmq2
    environment:
      - RABBITMQ_ERLANG_COOKIE=rahasiaCookie
    volumes:
      - rabbitmq2_data:/var/lib/rabbitmq

All nodes share the same cookie, then the nodes join through peer discovery — formation details follow the pattern from episode 19.

#Kubernetes Deployment

#The RabbitMQ Cluster Operator

The best way to deploy RabbitMQ on K8s is the RabbitMQ Cluster Operator — managing the StatefulSet, services, and configuration automatically via a CRD:

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: rabbit-prod
spec:
  replicas: 3
  persistence:
    storageClassName: standard
    storage: 10Gi
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: "2"
      memory: 4Gi

The RabbitmqCluster CRD asks the operator to build a 3-node cluster with a 10 GiB PersistentVolume and sensible resource request-limit.

#StatefulSets, ConfigMaps, and Secrets

The operator generates a StatefulSet (stable startup ordering), a ConfigMap for the rabbitmq.conf configuration, and Secrets for the default credentials and the cookie. All configuration changes go through K8s resources, not SSH into pods — this is the GitOps principle we deepen in episode 30.

#K8s Best Practices

#Headless Services and Peer Discovery

A cluster needs a headless service so each pod has a stable DNS name (rabbit-prod-0.rabbit-prod.rabbitmq.svc). The operator configures this automatically, and peer discovery uses that DNS to find sibling nodes.

#Probes and Rolling Updates

Kubernetes uses a liveness probe to restart stuck pods and a readiness probe to hold traffic until a pod is ready:

readinessProbe:
  exec:
    command: ["rabbitmq-diagnostics", "ping"]
  initialDelaySeconds: 20
livenessProbe:
  exec:
    command: ["rabbitmq-diagnostics", "status"]
  initialDelaySeconds: 30

For rolling updates, remove and replace pods one by one with intervals, so the cluster never loses a majority of nodes at once. The operator handles this when the image is updated.

#Resource Limits and HPA

Set requests and limits (as in the CRD above) so pods don't drain the node. HPA rarely fits stateful workloads like RabbitMQ — adding replica pods doesn't automatically fix a bottleneck, because queue data stays on its owner node. Measure first; if you need scalability, consider streams or topology design.

#Conclusion

In episode 29 you deployed RabbitMQ on Docker with env vars and volumes, built a cluster with Docker Compose, and deployed on Kubernetes with the RabbitMQ Cluster Operator, StatefulSets, PersistentVolumes, probes, and rolling update practices.

Key takeaways:

• Use the official image and environment variables for initial configuration.
• Volumes are mandatory for storing data that survives restarts.
• Docker Compose makes multi-node clusters easy on one host.
• The RabbitMQ Cluster Operator manages the cluster lifecycle on K8s.
• Headless services give stable DNS for peer discovery.
• Liveness and readiness probes matter for safe orchestration.
• HPA rarely fits stateful workloads like RabbitMQ.

In the next episode we will manage CI/CD, Infrastructure as Code, and GitOps — defining queues and exchanges as JSON definitions, automating with Terraform and Ansible, testing message flows with PerfTest, applying blue-green and canary releases, and automatic synchronization with ArgoCD and Flux. Infrastructure as code, starting now!