bitnamicharts/rabbitmq
Bitnami Helm chart for RabbitMQ
5M+
RabbitMQ is an open source general-purpose message broker that is designed for consistent, highly-available messaging scenarios (both synchronous and asynchronous).
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 install my-release oci://registry-1.docker.io/bitnamicharts/rabbitmq
Looking to use RabbitMQ in production? Try VMware Tanzu Application Catalog, the commercial edition of the Bitnami catalog.
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.
To install the chart with the release name my-release
:
helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/rabbitmq
Note: You need to substitute the placeholders
REGISTRY_NAME
andREPOSITORY_NAME
with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to useREGISTRY_NAME=registry-1.docker.io
andREPOSITORY_NAME=bitnamicharts
.
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
Bitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the resources
value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.
To make this process easier, the chart contains the resourcesPreset
values, which automatically sets the resources
section according to different presets. Check these presets in the bitnami/common chart. However, in production workloads using resourcesPreset
is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the official Kubernetes documentation.
This chart can be integrated with Prometheus by setting metrics.enabled
to true
. This enable the rabbitmq_prometheus plugin and expose a metrics endpoints in all pods and the RabbitMQ service. The service will have the necessary annotations to be automatically scraped by Prometheus.
Prometheus requirements
It is necessary to have a working installation of Prometheus or Prometheus Operator for the integration to work. Install the Bitnami Prometheus helm chart or the Bitnami Kube Prometheus helm chart to easily have a working Prometheus in your cluster.
Integration with Prometheus Operator
The chart can deploy ServiceMonitor
objects for integration with Prometheus Operator installations. There are different ServiceMonitor
objects per RabbitMQ endpoins. The chart includes:
metrics.serviceMonitor.default
for the /metrics
endpoint.metrics.serviceMonitor.perObject
for the /metrics/per-object
endpoint.metrics.serviceMonitor.detailed
for the /metrics/detailed
endpoint.Enable each ServiceMonitor by setting metrics.serviceMonitor.*.enabled=true
. Ensure that the Prometheus Operator CustomResourceDefinitions
are installed in the cluster or it will fail with the following error:
no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
Install the Bitnami Kube Prometheus helm chart for having the necessary CRDs and the Prometheus Operator.
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:
kubectl scale
command.replicaCount
parameter. replicaCount=3
auth.password="$RABBITMQ_PASSWORD"
auth.erlangCookie="$RABBITMQ_ERLANG_COOKIE"
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. Otherwise, new pods won't be able to join the cluster.
When scaling down the solution, unnecessary RabbitMQ nodes are automatically stopped, but they are not removed from the cluster. These nodes must be manually removed via the rabbitmqctl forget_cluster_node
command.
For instance, if RabbitMQ was initially installed with three replicas and then scaled down to two replicas, run the commands below (assuming that the release name is rabbitmq
and the clustering type is hostname
):
kubectl exec rabbitmq-0 --container rabbitmq -- rabbitmqctl forget_cluster_node rabbit@rabbitmq-2.rabbitmq-headless.default.svc.cluster.local
kubectl delete pvc data-rabbitmq-2
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.
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:
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.
This chart also facilitates the creation of TLS secrets for use with the Ingress controller (although this is not mandatory). There are several common use cases:
In the first two cases, a certificate and a key are needed. Files are expected in .pem
format.
Here is an example of a certificate file:
NOTE: There may be more than one certificate if there is a certificate chain.
-----BEGIN CERTIFICATE-----
MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
...
jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7
-----END CERTIFICATE-----
Here is an example of a certificate key:
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4
...
wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc=
-----END RSA PRIVATE KEY-----
certificate
and key
values for a given *.ingress.secrets
entry.INGRESS_HOSTNAME-tls
(where INGRESS_HOSTNAME is a placeholder to be replaced with the hostname you set using the *.ingress.hostname
parameter).*.ingress.annotations
the corresponding ones for cert-manager.*.ingress.tls
and *.ingress.selfSigned
to true
.It is possible to load a RabbitMQ definitions file to configure RabbitMQ. Follow the steps below:
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. Here is an example:
auth:
password: CHANGEME
extraSecrets:
load-definition:
load_definition.json: |
{
"users": [
{
"name": "{{ .Values.auth.username }}",
"password": "{{ .Values.auth.password }}",
"tags": "administrator"
}
],
"vhosts": [
{
"name": "/"
}
]
}
loadDefinition:
enabled: true
existingSecret: load-definition
extraConfiguration: |
load_definitions = /app/load_definition.json
The Bitnami RabbitMQ chart, when upgrading, reuses the secret previously rendered by the chart or the one specified in auth.existingSecret
. To update credentials, use one of the following:
helm upgrade
specifying a new password in auth.password
and auth.updatePassword=true
.helm upgrade
specifying a new secret in auth.existingSecret
and auth.updatePassword=true
.LDAP support can be enabled in the chart by specifying the ldap.*
parameters while creating a release. For example:
ldap.enabled="true"
ldap.server="my-ldap-server"
ldap.port="389"
ldap.user_dn_pattern="cn=${username},dc=example,dc=org"
If ldap.tls.enabled
is set to true, consider using ldap.port=636
and checking the settings in the advancedConfiguration
chart parameters.
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:
memoryHighWatermark.enabled="true"
memoryHighWatermark.type="absolute"
memoryHighWatermark.value="512Mi"
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.
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 = .*
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.
communityPlugins="http://URL-TO-PLUGIN/"
extraPlugins="my-custom-plugin"
In case you want to configure RabbitMQ logging set logs
value to false and set the log config in extraConfiguration following the official documentation.
An example:
logs: false # custom logging
extraConfiguration: |
log.default.level = warning
log.file = false
log.console = true
log.console.level = warning
log.console.formatter = json
RabbitMQ nodes assume their peers come back online within five minutes (by default). When the OrderedReady
pod management policy is used with a readiness probe that implicitly requires a fully booted node, the deployment can deadlock:
The following combination of deployment settings avoids the problem:
podManagementPolicy: "Parallel"
to boot multiple cluster nodes in parallelrabbitmq-diagnostics ping
for readiness probeTo learn more, please consult RabbitMQ documentation guides:
Do Not Force Boot Nodes on a Regular Basis
Note that forcing nodes to boot is not a solution and doing so can be dangerous. Forced booting is a last resort mechanism in RabbitMQ that helps make remaining cluster nodes recover and rejoin each other after a permanent loss of some of their former peers. In other words, forced booting a node is an emergency event recovery procedure.
To back up and restore Helm chart deployments on Kubernetes, you need to back up the persistent volumes from the source deployment and attach them to a new deployment using Velero, a Kubernetes backup/restore tool. Find the instructions for using Velero in this guide.
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.
helm install my-release --set persistence.existingClaim=PVC_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/rabbitmq
Note: You need to substitute the placeholders
REGISTRY_NAME
andREPOSITORY_NAME
with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to useREGISTRY_NAME=registry-1.docker.io
andREPOSITORY_NAME=bitnamicharts
.
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
.
RabbitMQ has built-in support for Prometheus metrics
exposed at GET /metrics
. However, these metrics are all cluster-wide, and do not show any per-queue or per-node
metrics.
To get per-object metrics, there is a
second metrics endpoint at GET /metrics/detailed
that
accepts query parameters to choose which metric families you would like to see. For instance, you can pass
family=node_coarse_metrics&family=queue_coarse_metrics
to see per-node and per-queue metrics, but with no need to see
Erlang, connection, or channel metrics.
Additionally, there is a third metrics endpoint:
GET /metrics/per-object
. which returns all per-object metrics. However, this can be computationally expensive on a
large cluster with many objects, and so RabbitMQ docs suggest using GET /metrics/detailed
mentioned above to filter
your scraping and only fetch the per-object metrics that are needed for a given monitoring application.
Because they expose different sets of data, a valid use case is to scrape metrics from both GET /metrics
and
GET /metrics/detailed
, ingesting both cluster-level and per-object metrics. The metrics.serviceMonitor.default
and
metrics.serviceMonitor.detailed
values support configuring a ServiceMonitor that targets one or both of these metrics.
Name | Description | Value |
---|---|---|
global.imageRegistry | Global Docker image registry | "" |
global.imagePullSecrets | Global Docker registry secret names as an array | [] |
global.defaultStorageClass | Global default StorageClass for Persistent Volume(s) | "" |
global.storageClass | DEPRECATED: use global.defaultStorageClass instead | "" |
global.security.allowInsecureImages | Allows skipping image verification | false |
global.compatibility.openshift.adaptSecurityContext | Adapt the securityContext sections of the deployment to make them compatible with Openshift restricted-v2 SCC: remove runAsUser, runAsGroup and fsGroup and let the platform use their allowed default IDs. Possible values: auto (apply if the detected running cluster is Openshift), force (perform the adaptation always), disabled (do not perform adaptation) | auto |
Name | Description | Value |
---|---|---|
image.registry | RabbitMQ image registry | REGISTRY_NAME |
image.repository | RabbitMQ image repository | REPOSITORY_NAME/rabbitmq |
image.digest | RabbitMQ image digest in the way |
Note: the README for this chart is longer than the DockerHub length limit of 25000, so it has been trimmed. The full README can be found at https://github.com/bitnami/charts/blob/main/bitnami/rabbitmq/README.md