Skip to main content

Deploying in Containers

1. Using Official Docker Image

Property Value Description
Image rabbitmq:latest Official RabbitMQ Docker image
Ports 5672, 15672 AMQP and Management API ports
Environment Variables RABBITMQ_DEFAULT_USER, RABBITMQ_DEFAULT_PASS Default user credentials for management

Example: Run RabbitMQ with Docker

docker run -d --name my-rabbit \
  -p 5672:5672 -p 15672:15672 \
  -e RABBITMQ_DEFAULT_USER=myuser \
  -e RABBITMQ_DEFAULT_PASS=mypass \
  rabbitmq:latest
Note: The management plugin is enabled by default in the official image.

2. Configuring via Environment Variables

Environment Variable Default Value Description Notes
RABBITMQ_DEFAULT_USER guest Username for default user Used when RABBITMQ_DEFAULT_PASS is set
RABBITMQ_DEFAULT_PASS guest Password for default user Used when RABBITMQ_DEFAULT_USER is set
RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS Additional Erlang arguments to pass to the RabbitMQ server Useful for setting custom flags or configurations
RABBITMQ_NODENAME rabbit@localhost Node name for the RabbitMQ instance Must be unique in a cluster
RABBITMQ_USE_LONGNAME false Whether to use long node names (e.g., rabbit@hostname) Set to true for distributed setups
RABBITMQ_PORT 5672 Port to bind the AMQP protocol listener Can be overridden for custom port binding
RABBITMQ_MANAGEMENT_PORT 15672 Port to bind the management plugin HTTP listener Used for web-based administration
RABBITMQ_SSL_PORT 5671 Port to bind the AMQP/SSL protocol listener Requires SSL configuration
RABBITMQ_SSL_CERTFILE Path to the SSL certificate file Used when RABBITMQ_SSL_PORT is set
RABBITMQ_SSL_KEYFILE Path to the SSL key file Used when RABBITMQ_SSL_PORT is set
RABBITMQ_SSL_CAFILE Path to the CA certificate file Used for client certificate verification
RABBITMQ_SSL_VERIFY verify_none SSL verification mode Options: verify_none, verify_peer
RABBITMQ_SSL_FAIL_IF_NO_PEER_CERT false Whether to fail if no peer certificate is provided Applicable only when RABBITMQ_SSL_VERIFY is set to verify_peer
RABBITMQ_SSL_DEPTH 1 Maximum depth of certificate chains to verify Used in conjunction with RABBITMQ_SSL_VERIFY
RABBITMQ_SSL_PASSWORD Password for encrypted SSL key files Used when RABBITMQ_SSL_KEYFILE is encrypted
RABBITMQ_PLUGINS_DIR /opt/rabbitmq/plugins Directory where plugins are stored Can be overridden to load custom plugins
RABBITMQ_CONFIG_FILE /etc/rabbitmq/rabbitmq.conf Path to the main configuration file Overrides default config location
RABBITMQ_LOGS /var/log/rabbitmq Directory for log files Used to store logs from RabbitMQ
RABBITMQ_MNESIA_BASE /var/lib/rabbitmq/mnesia Base directory for Mnesia database files Used to store persistent data
RABBITMQ_PID_FILE /var/run/rabbitmq.pid Path to the PID file for RabbitMQ process Used to manage the RabbitMQ daemon

Example: Setting up RabbitMQ with Environment Variables

docker run -d \
  --name my-rabbit \
  -e RABBITMQ_DEFAULT_USER=myuser \
  -e RABBITMQ_DEFAULT_PASS=mypass \
  -e RABBITMQ_PORT=5672 \
  -e RABBITMQ_MANAGEMENT_PORT=15672 \
  rabbitmq:latest
Note: When using environment variables for configuration, ensure that sensitive values like passwords are not exposed in logs or command-line arguments.

3. Mounting Configuration Files

Example: Mounting RabbitMQ Configuration

version: '3.8'
services:
  rabbitmq:
    image: rabbitmq:3.12-management
    volumes:
      - ./rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf
      - ./definitions.json:/etc/rabbitmq/definitions.json
    ports:
      - "5672:5672"
      - "15672:15672"
Volume Mount Description Notes
/etc/rabbitmq/rabbitmq.conf config file for RabbitMQ Must be readable by the RabbitMQ user
/etc/rabbitmq/definitions.json JSON file with queue/exchange definitions Used for automatic setup on startup
Note: Ensure the mounted files have correct permissions to be read by the container user (typically UID 999).

4. Setting Resource Limits

Example: Docker Compose with Resource Limits

version: '3.8'
services:
  rabbitmq:
    image: rabbitmq:3.12-management
    deploy:
      resources:
        limits:
          memory: 1G
          cpus: '0.5'
        reservations:
          memory: 512M
          cpus: '0.25'
Resource Configuration Description
memory 1G Maximum memory limit for the container
cpus 0.5 Number of CPU cores to limit to (0.5 = half a core)
Note: Resource limits should be set based on the expected load and available system resources to prevent container starvation or system instability.

5. Deploying on Kubernetes

Example: RabbitMQ Deployment in Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rabbitmq-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rabbitmq
  template:
    metadata:
      labels:
        app: rabbitmq
    spec:
      containers:
      - name: rabbitmq
        image: rabbitmq:3.12-management
        ports:
        - containerPort: 5672
        - containerPort: 15672
        env:
        - name: RABBITMQ_DEFAULT_USER
          value: "admin"
        - name: RABBITMQ_DEFAULT_PASS
          value: "password"
Property Value Description
image rabbitmq:3.12-management Official RabbitMQ image with management plugin
containerPort 5672 AMQP protocol port
containerPort 15672 Management UI port
Note: Ensure persistent storage is configured for production use to avoid data loss during pod restarts.

Example: RabbitMQ Service Configuration

apiVersion: v1
kind: Service
metadata:
  name: rabbitmq-service
spec:
  selector:
    app: rabbitmq
  ports:
    - protocol: TCP
      port: 5672
      targetPort: 5672
    - protocol: TCP
      port: 15672
      targetPort: 15672
  type: ClusterIP

Key Considerations for Kubernetes Deployment

  • Use persistent volumes for message persistence
  • Configure liveness and readiness probes
  • Set appropriate resource limits to prevent overconsumption
  • Enable TLS for secure communication between pods

6. Using Helm Charts

Example: Deploying RabbitMQ with Helm

helm repo add rabbitmq https://charts.rabbitmq.com/
helm install my-rabbitmq rabbitmq/rabbitmq
Parameter Description Default Value
image.repository Image repository for RabbitMQ rabbitmq
image.tag Image tag to use 3.12.10
persistence.enabled Enable persistence for data storage true
service.type Kubernetes service type (e.g., ClusterIP, NodePort) ClusterIP
Note: Ensure that the storageClass is properly configured if using custom storage.
Warning: The default configuration does not include authentication. It is recommended to configure credentials for production use.

7. Configuring Cluster Operator

Example: Basic RabbitMQ Cluster Configuration

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: example-rabbitmq
spec:
  replicas: 3
  resources:
    limits:
      cpu: "2"
      memory: 2Gi
    requests:
      cpu: "1"
      memory: 1Gi
  storage:
    storageClassName: standard
    resources:
      requests:
        storage: 10Gi
Property Description Default Value Notes
replicas Number of RabbitMQ nodes in the cluster 1 Must be at least 1
resources.limits.cpu Maximum CPU allocation per node 2 Can be specified as a decimal or integer
resources.limits.memory Maximum memory allocation per node 2Gi Must be a valid Kubernetes resource quantity
storage.storageClassName StorageClass to use for persistent volumes default Must exist in the cluster
storage.resources.requests.storage Storage size requested per node 10Gi Must be a valid Kubernetes resource quantity
Note: Ensure that the rabbitmq.com CRD is installed in your cluster before applying this configuration.
Warning: Changing replicas after initial deployment may cause data loss or require manual intervention.

Configuration Summary

  • Replicas: Defines the number of RabbitMQ nodes in the cluster
  • Resources: Sets CPU and memory limits for each node
  • Storage: Configures persistent storage using Kubernetes StorageClass

8. Implementing Persistent Storage

Example: Docker Compose with Persistent Storage

version: '3.8'
services:
  rabbitmq:
    image: rabbitmq:3-management
    volumes:
      - rabbitmq_data:/var/lib/rabbitmq
      - rabbitmq_logs:/var/log/rabbitmq
    ports:
      - "5672:5672"
      - "15672:15672"
volumes:
  rabbitmq_data:
  rabbitmq_logs:
Volume Mount Path Description
rabbitmq_data /var/lib/rabbitmq Stores message queues, exchanges, and definitions
rabbitmq_logs /var/log/rabbitmq Stores log files for debugging and monitoring
Note: Ensure that the volume permissions are correctly set to allow RabbitMQ to read/write to the mounted directories.
Warning: Without persistent storage, all messages and configuration will be lost when the container is stopped or removed.

9. Configuring Health Probes

Probe Type Endpoint Configuration Notes
livenessProbe /api/health
{
  "livenessProbe": {
    "httpGet": {
      "path": "/api/health",
      "port": 15672
    },
    "initialDelaySeconds": 30,
    "periodSeconds": 10
  }
}
Indicates if the container is running and healthy
readinessProbe /api/health
{
  "readinessProbe": {
    "httpGet": {
      "path": "/api/health",
      "port": 15672
    },
    "initialDelaySeconds": 30,
    "periodSeconds": 5
  }
}
Indicates if the container is ready to serve requests

Example: Kubernetes Deployment with Health Probes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rabbitmq-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rabbitmq
  template:
    metadata:
      labels:
        app: rabbitmq
    spec:
      containers:
      - name: rabbitmq
        image: rabbitmq:3.12-management
        ports:
        - containerPort: 5672
        - containerPort: 15672
        livenessProbe:
          httpGet:
            path: /api/health
            port: 15672
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /api/health
            port: 15672
          initialDelaySeconds: 30
          periodSeconds: 5
Note: The /api/health endpoint is available when RabbitMQ Management Plugin is enabled.

10. Managing Secrets

Example: Environment-based secret injection

version: '3.8'
services:
  rabbitmq:
    image: rabbitmq:3-management
    environment:
      RABBITMQ_DEFAULT_USER: "admin"
      RABBITMQ_DEFAULT_PASS: "${RABBITMQ_PASSWORD}"
    volumes:
      - ./rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf
Secret Source Configuration Method Notes
Environment Variables RABBITMQ_DEFAULT_USER, RABBITMQ_DEFAULT_PASS Standard method for credential injection in containers
Volume Mounts /etc/rabbitmq/rabbitmq.conf Use for complex configurations or sensitive files
Kubernetes Secrets secretKeyRef Securely inject secrets into pods
Note: Avoid hardcoding credentials in Dockerfiles or image builds.
Warning: Ensure proper file permissions on mounted secret files (e.g., 600).

Best Practices for Secret Management

  • Use environment variables or secret volumes for credentials
  • Never store secrets in plain text in configuration files
  • Rotate credentials regularly and update secret stores accordingly

11. Setting Up Auto-Scaling

Example: RabbitMQ Auto-Scaling Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rabbitmq-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rabbitmq
  template:
    metadata:
      labels:
        app: rabbitmq
    spec:
      containers:
      - name: rabbitmq
        image: rabbitmq:3.12-management
        ports:
        - containerPort: 5672
        - containerPort: 15672
        env:
        - name: RABBITMQ_DEFAULT_USER
          value: "admin"
        - name: RABBITMQ_DEFAULT_PASS
          value: "password"
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
Property Description Default Value Notes
replicas Number of RabbitMQ instances to run 1 Adjust based on load and availability needs
resources.requests.memory Minimum memory requested per pod 512Mi Ensures pods get sufficient memory to start
resources.limits.memory Maximum memory allowed per pod 1Gi Prevents pods from consuming too much memory
resources.requests.cpu Minimum CPU requested per pod 250m Ensures pods get adequate CPU to function
resources.limits.cpu Maximum CPU allowed per pod 500m Prevents pods from monopolizing CPU resources
Note: Auto-scaling in containerized environments requires proper resource limits and monitoring tools like Prometheus or Kubernetes HPA (Horizontal Pod Autoscaler) to effectively scale based on metrics such as queue length or message throughput.

Workflow: Configuring Auto-Scaling for RabbitMQ

  1. Create a Kubernetes Deployment with appropriate resource requests and limits
  2. Deploy a Horizontal Pod Autoscaler (HPA) to scale based on CPU or memory usage
  3. Monitor queue depth and message rate using RabbitMQ's management plugin or external tools
  4. Adjust HPA configuration to respond to changing load patterns

12. Monitoring Container Metrics

Example: RabbitMQ Container Metrics

docker stats rabbitmq-container
Metric Description Collection Method Notes
CPU Usage Percentage of CPU used by the container docker stats Includes system and user time
Memory Usage Current memory consumption of the container docker stats May include cache and buffers
Network I/O Bytes sent and received over network interfaces docker stats Can be filtered by interface
Disk I/O Read and write operations on disk docker stats Requires host-level access to metrics
Note: For detailed RabbitMQ-specific metrics, integrate with Prometheus or use built-in management plugins.

Example: Prometheus Metrics Endpoint

scrape_configs:
  - job_name: 'rabbitmq'
    static_configs:
      - targets: ['localhost:15692']

Was this article helpful?