RabbitMQ is an open source general-purpose message broker that is designed for consistent, highly-available messaging scenarios (both synchronous and asynchronous).

Overview of RabbitMQ

Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/rabbitmq

This chart bootstraps a RabbitMQ deployment on a Kubernetes cluster using the Helm package manager.

Bitnami charts can be used with Kubeapps for deployment and management of Helm Charts in clusters. This chart has been tested to work with NGINX Ingress, cert-manager, fluentd and Prometheus on top of the BKPR.

• Kubernetes 1.19
• Helm 3.2.0
• PV provisioner support in the underlying infrastructure

To install the chart with the release name my-release:

$ helm install my-release bitnami/rabbitmq

The command deploys RabbitMQ on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

To uninstall/delete the my-release deployment:

$ helm delete my-release

The command removes all the Kubernetes components associated with the chart and deletes the release.

The above parameters map to the env variables defined in bitnami/rabbitmq. For more information please refer to the bitnami/rabbitmq image documentation.

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

$ helm install my-release \
  --set auth.username=admin,auth.password=secretpassword,auth.erlangCookie=secretcookie \
    bitnami/rabbitmq

The above command sets the RabbitMQ admin username and password to admin and secretpassword respectively. Additionally the secure erlang cookie is set to secretcookie.

NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available.

Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example,

$ helm install my-release -f values.yaml bitnami/rabbitmq

Tip: You can use the default values.yaml

It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.

This chart allows you to set your custom affinity using the affinity parameter. Find more information about Pod's affinity in the kubernetes documentation.

As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the bitnami/common chart. To do so, set the podAffinityPreset, podAntiAffinityPreset, or nodeAffinityPreset parameters.

To horizontally scale this chart once it has been deployed, two options are available:

• Use the kubectl scale command.
• Upgrade the chart modifying the replicaCount parameter.

NOTE: It is mandatory to specify the password and Erlang cookie that was set the first time the chart was installed when upgrading the chart.

When scaling down the solution, unnecessary RabbitMQ nodes are automatically stopped, but they are not removed from the cluster. You need to manually remove them by running the rabbitmqctl forget_cluster_node command.

Refer to the chart documentation for more information on scaling the Rabbit cluster horizontally.

To enable TLS support, first generate the certificates as described in the RabbitMQ documentation for SSL certificate generation.

Once the certificates are generated, you have two alternatives:

• Create a secret with the certificates and associate the secret when deploying the chart
• Include the certificates in the values.yaml file when deploying the chart

Set the auth.tls.failIfNoPeerCert parameter to false to allow a TLS connection if the client fails to provide a certificate.

Set the auth.tls.sslOptionsVerify to verify_peer to force a node to perform peer verification. When set to verify_none, peer verification will be disabled and certificate exchange won't be performed.

Refer to the chart documentation for more information and examples of enabling TLS and using Let's Encrypt certificates.

It is possible to load a RabbitMQ definitions file to configure RabbitMQ.

Because definitions may contain RabbitMQ credentials, store the JSON as a Kubernetes secret. Within the secret's data, choose a key name that corresponds with the desired load definitions filename (i.e. load_definition.json) and use the JSON object as the value.

Next, specify the load_definitions property as an extraConfiguration pointing to the load definition file path within the container (i.e. /app/load_definition.json) and set loadDefinition.enable to true. Any load definitions specified will be available within in the container at /app.

NOTE: Loading a definition will take precedence over any configuration done through Helm values.

If needed, you can use extraSecrets to let the chart create the secret for you. This way, you don't need to manually create it before deploying a release. These secrets can also be templated to use supplied chart values.

Refer to the chart documentation for more information and configuration examples of loading custom definitions.

LDAP support can be enabled in the chart by specifying the ldap.* parameters while creating a release. Refer to the chart documentation for more information and a configuration example.

It is possible to configure a memory high watermark on RabbitMQ to define memory thresholds using the memoryHighWatermark.* parameters. To do so, you have two alternatives:

• Set an absolute limit of RAM to be used on each RabbitMQ node, as shown in the configuration example below:

memoryHighWatermark.enabled="true"
memoryHighWatermark.type="absolute"
memoryHighWatermark.value="512MB"

• Set a relative limit of RAM to be used on each RabbitMQ node. To enable this feature, define the memory limits at pod level too. An example configuration is shown below:

memoryHighWatermark.enabled="true"
memoryHighWatermark.type="relative"
memoryHighWatermark.value="0.4"
resources.limits.memory="2Gi"

In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the extraEnvVars property.

extraEnvVars:
  - name: LOG_LEVEL
    value: error

Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the .extraEnvVarsCM or the extraEnvVarsSecret properties.

The Bitnami Docker RabbitMQ image ships a set of plugins by default. By default, this chart enables rabbitmq_management and rabbitmq_peer_discovery_k8s since they are required for RabbitMQ to work on K8s.

To enable extra plugins, set the extraPlugins parameter with the list of plugins you want to enable. In addition to this, the communityPlugins parameter can be used to specify a list of URLs (separated by spaces) for custom plugins for RabbitMQ.

Refer to the chart documentation for more information on using RabbitMQ plugins.

IMPORTANT: Some of these procedures can lead to data loss. Always make a backup beforehand.

The RabbitMQ cluster is able to support multiple node failures but, in a situation in which all the nodes are brought down at the same time, the cluster might not be able to self-recover.

This happens if the pod management policy of the statefulset is not Parallel and the last pod to be running wasn't the first pod of the statefulset. If that happens, update the pod management policy to recover a healthy state:

$ kubectl delete statefulset STATEFULSET_NAME --cascade=false
$ helm upgrade RELEASE_NAME bitnami/rabbitmq \
    --set podManagementPolicy=Parallel \
    --set replicaCount=NUMBER_OF_REPLICAS \
    --set auth.password=PASSWORD \
    --set auth.erlangCookie=ERLANG_COOKIE

For a faster resyncronization of the nodes, you can temporarily disable the readiness probe by setting readinessProbe.enabled=false. Bear in mind that the pods will be exposed before they are actually ready to process requests.

If the steps above don't bring the cluster to a healthy state, it could be possible that none of the RabbitMQ nodes think they were the last node to be up during the shutdown. In those cases, you can force the boot of the nodes by specifying the clustering.forceBoot=true parameter (which will execute rabbitmqctl force_boot in each pod):

$ helm upgrade RELEASE_NAME bitnami/rabbitmq \
    --set podManagementPolicy=Parallel \
    --set clustering.forceBoot=true \
    --set replicaCount=NUMBER_OF_REPLICAS \
    --set auth.password=PASSWORD \
    --set auth.erlangCookie=ERLANG_COOKIE

More information: Clustering Guide: Restarting.

• Changing the password through RabbitMQ's UI can make the pod fail due to the default liveness probes. If you do so, remember to make the chart aware of the new password. Updating the default secret with the password you set through RabbitMQ's UI will automatically recreate the pods. If you are using your own secret, you may have to manually recreate the pods.

The Bitnami RabbitMQ image stores the RabbitMQ data and configurations at the /opt/bitnami/rabbitmq/var/lib/rabbitmq/ path of the container.

The chart mounts a Persistent Volume at this location. By default, the volume is created using dynamic volume provisioning. An existing PersistentVolumeClaim can also be defined.

1. Create the PersistentVolume
2. Create the PersistentVolumeClaim
3. Install the chart

$ helm install my-release --set persistence.existingClaim=PVC_NAME bitnami/rabbitmq

As the image runs as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it.

By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination.

You can enable this initContainer by setting volumePermissions.enabled to true.

If you want to create default user/vhost and set the default permission. you can use extraConfiguration:

auth:
  username: default-user
extraConfiguration: |-
  default_vhost = default-vhost
  default_permissions.configure = .*
  default_permissions.read = .*
  default_permissions.write = .*

Find more information about how to deal with common errors related to Bitnami's Helm charts in this troubleshooting guide.

It's necessary to set the auth.password and auth.erlangCookie parameters when upgrading for readiness/liveness probes to work properly. When you install this chart for the first time, some notes will be displayed providing the credentials you must use under the 'Credentials' section. Please note down the password and the cookie, and run the command below to upgrade your chart:

$ helm upgrade my-release bitnami/rabbitmq --set auth.password=[PASSWORD] --set auth.erlangCookie=[RABBITMQ_ERLANG_COOKIE]

| Note: you need to substitute the placeholders [PASSWORD] and [RABBITMQ_ERLANG_COOKIE] with the values obtained in the installation notes.

This new version of the chart bumps the RabbitMQ version to 3.9.1. It is considered a minor release, and no breaking changes are expected. Additionally, RabbitMQ 3.9.X nodes can run alongside 3.8.X nodes.

See the Upgrading guide and the RabbitMQ change log for further documentation.

On November 13, 2020, Helm v2 support was formally finished, this major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL.

Learn more about this change and related upgrade considerations.

• Several parameters were renamed or disappeared in favor of new ones on this major version:
  • replicas is renamed to replicaCount.
  • securityContext.* is deprecated in favor of podSecurityContext and containerSecurityContext.
  • Authentication parameters were reorganized under the auth.* parameter:
    • rabbitmq.username, rabbitmq.password, and rabbitmq.erlangCookie are now auth.username, auth.password, and auth.erlangCookie respectively.
    • rabbitmq.tls.* parameters are now under auth.tls.*.
  • Parameters prefixed with rabbitmq. were renamed removing the prefix. E.g. rabbitmq.configuration -> renamed to configuration.
  • rabbitmq.rabbitmqClusterNodeName is deprecated.
  • rabbitmq.setUlimitNofiles is deprecated.
  • forceBoot.enabled is renamed to clustering.forceBoot.
  • loadDefinition.secretName is renamed to loadDefinition.existingSecret.
  • metics.port is remamed to service.metricsPort.
  • service.extraContainerPorts is renamed to extraContainerPorts.
  • service.nodeTlsPort is renamed to service.tlsNodePort.
  • podDisruptionBudget is deprecated in favor of pdb.create, pdb.minAvailable, and pdb.maxUnavailable.
  • rbacEnabled -> deprecated in favor of rbac.create.
  • New parameters: serviceAccount.create, and serviceAccount.name.
  • New parameters: memoryHighWatermark.enabled, memoryHighWatermark.type, and memoryHighWatermark.value.
• Chart labels and Ingress configuration were adapted to follow the Helm charts best practices.
• Initialization logic now relies on the container.
• This version introduces bitnami/common, a library chart as a dependency. More documentation about this new utility could be found here. Please, make sure that you have updated the chart dependencies before executing any upgrade.

Consequences:

• Backwards compatibility is not guaranteed.
• Compatibility with non Bitnami images is not guaranteed anymore.

This new version updates the RabbitMQ image to a new version based on bash instead of node.js. However, since this Chart overwrites the container's command, the changes to the container shouldn't affect the Chart. To upgrade, it may be needed to enable the fastBoot option, as it is already the case from upgrading from 5.X to 5.Y.

This major release changes the clustering method from ip to hostname. This change is needed to fix the persistence. The data dir will now depend on the hostname which is stable instead of the pod IP that might change.

IMPORTANT: Note that if you upgrade from a previous version you will lose your data.

Backwards compatibility is not guaranteed unless you modify the labels used on the chart's deployments. Use the workaround below to upgrade from versions previous to 3.0.0. The following example assumes that the release name is rabbitmq:

$ kubectl delete statefulset rabbitmq --cascade=false

Bitnami Kubernetes documentation is available at https://docs.bitnami.com/. You can find there the following resources:

• Documentation for RabbitMQ Helm chart
• Get Started with Kubernetes guides
• Bitnami Helm charts documentation
• Kubernetes FAQs
• Kubernetes Developer guides

Copyright © 2022 Bitnami

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.