I recently got to experience deploying RabbitMQ-HA via Rancher’s Helm package. The experience was pretty good, though our cluster doesn’t act like many clusters. The cluster is hosted in Azure and is can be considered an extension of our datacenter. In a large enterprise, this comes with issues such as IP address space being limited, so in 90% of our cases, traffic is only exposed via an Ingress. In our case, this is an Azure Internal LoadBalancer pointed at an IaaS deployment of kubernetes.
When deploying an HA environment of RabbitMQ, one thing that you may desire is persistence, which means persistent storage in Kubernetes. This can be troublesome depending on your implementation. In our case, this implementation is Azure files. In order to get this to work properly, there’s a few things you’ll want to do. First, create a storage class. In my environment, I named this ‘RabbitMQ’. Choose Azure Files as the type of storage and fill in the blanks. Items of importance for this class to work are adding the following options for the device:
The file mode is the interesting part, but the uid and gid match what’s in the default helm chart for the rabbitMQ deployment. The file mode is required because rabbitMQ loses it’s mind when anyone other than the user running RabbitMQ can read the erlang cookie secret file.