[RabbitMQ] Allow adding custom startup scripts

[DiamondJoseph]

For my RabbitMQ instance, I need a second user without admin permissions (previously I had an admin account with permission for the management console, with password mounted from a secret and a user account for sending/reading from all queues with "guest").

This was being managed by running all scripts mounted in a named ConfigMap at startup, and defining that ConfigMap from a short shell script. I've only briefly looked at the definition of the initContainer and the scripts ConfigMap, so I may have missed something obvious, but I would like a way to achieve some of the same behaviour without losing what the current init scripts are doing.

[groundhog2k]

I understand what you would like to achieve.
The init phase is definitely too early to do that, because the RabbitMQ instance in the pod is not available at that point in time. The only thing I can imagine is to add a optional script part to startup.sh in the scripts ConfigMap to allow additional commands in the containers portStart phase. Of course this solution works well, for a single instance, but if you have a HA cluster of multiple RabbitMQ pods, than this additional script will be executed for every pod and potentially fail, because the user already exists.
Thats the problem I couldn't get my head around. For your scenario you don't want to execute the script every time the pod restarts, but only once.
Anyway I think I have a better solution for you - without scripting at all.

You can import your users (or everything you like) with a definiton file - and the best thing, it will not overwrite existing definitions. Take a look at https://www.rabbitmq.com/docs/definitions#import-on-boot

All you have to to is create and deploy a ConfigMap like:

apiVersion: v1
kind: ConfigMap
metadata:
  name: bunny-defs
data:
  definitions.json: |
    {
        "users": [
            {
                "name": "userB",
                "password_hash": "/TgZGravOlXfEL8R5yUJ4I3twxC8tRdV2yCFjAefCEqi29qv",
                "hashing_algorithm": "rabbit_password_hashing_sha256",
                "tags": [
                    "management"
                ],
                "limits": {}
            }
        ],
        "permissions": [

            {
                "user": "userB",
                "vhost": "/",
                "configure": ".*",
                "write": ".*",
                "read": ".*"
            }
        ]
    }

For the RabbitMQ deployment you have to adapt the values.yaml, mount the ConfigMap with the definition file and let RabbitMQ automatically import it during boot time:

customConfig: |
  definitions.import_backend = local_filesystem
  definitions.local.path = /backup/definitions.json

## A list of additional existing configMaps that will be mounted into the container
extraConfigs:
    ## Name of the existing K8s configMap
  - name: bunny-defs
    ## Mount path where the configMap should be mounted into the container (f.e. /mysecretfolder)
    mountPath: /backup

! Keep attention to the passwort hash in the definitions file above, this will only work for the personal instance, because of the erlang cookie.

However, this approach will make it possible to backup the actual configuration (using the export feature from the management UI or console) and restore all or parts of the configuration during a deployment.

[DiamondJoseph]

I'm not sure if I can easily solve it by mounting a definitions.json from a ConfigMap- I'd like my passwords to be mounted from a SealedSecret so I can have them committed to the repository (we have ~30 internal and 4 external repositories for experimental hardware), I did like how the existing handling for the admin user/password is being done

    existingSecret: rabbitmq-secrets
    user:
      value: admin
    password:
      secretKey: rabbitmq-password
    erlangCookie:
      secretKey: rabbitmq-erlang-cookie

[groundhog2k]

The definitions.json could also be stored in a git repo and passwords are protected because of hash. But I see the point..
I disassembled the bitnami chart and they use an additional docker-entrypoint folder for all init-scripts. That is additional logic in the docker image itself that the community docker image for RabbitMQ doesn't provide.

Maybe I can inject some additional scripting in the postStart:-phase of the container.
I'm curious: Do you use RabbitMQ in HA cluster mode for your setup? (I'm not sure if your init script will really work in this case, because the first node will create all users but for the others the script should fail, because users already exist - in best case the error is ignored, but it's not a clean solution for HA cluster setups)

[DiamondJoseph]

We're not currently using the HA functionality.
RabbitMQ was intended as a transition stage in moving to a services architecture- we're supporting a >20 year old Java monolith which has been using ActiveMQ flavour JMS for ~15 years. We decoupled it from ActiveMQ specific JMS to use RMQ as some support teams reported a lot of instability, and used it as an opportunity to move the message bus into our cluster as RMQ ha[d] a well supported Helm chart but AMQ didn't. We're therefore using the JMS plugin and for the new system & to support other teams the Stomp plugin.

It's intended to cut off the need for the message bus in the short-medium term, so it's only needed to be "better than it was". The liveness probes in kubernetes were already preventing the worst behaviour of freezing and visiting users not having permissions to restart the service.

[groundhog2k]

I still see no quick solution without an entrypoint hook which needs to be the container image itself 🧐

[peter-englmaier]

I am having a similar issue, migrating from bitanmi to your chart ;-) I think I can mount extra configuration params like this:

# Create a secret "extraconfig" with content:
# extraconfig.yaml:
#  definitions.import_backend = local_filesystem
#  definitions.local.path = /app/load_definition.json

extraSecretConfigs: extraconfig

But I am stuck in mounting the secret holding the load_definitions.json to /app/load_definintion.json or somewhere else.

[groundhog2k]

Use the extraSecrets: section (see values.yaml) for mounting your secret into the container:

## A list of additional existing secrets that will be mounted into the container
## The mounted files of the secrets can be used for advanced configuration - f.e. TLS
extraSecrets: []
    ## Name of the existing K8s secret
#  - name:
    ## Mount default mode (0440 if parameter is omitted)
#    defaultMode: 0440
    ## Mount path where the secret should be mounted into the container (f.e. /mysecretfolder)
#    mountPath:

So in your case (your secret with name "extraconfig" contains a file called 'load_definition.json'):

extraSecrets:
  - name: extraconfig
    mountPath: /app

[peter-englmaier]

Thanks, yes this works perfectly!

[groundhog2k]

@DiamondJoseph : Please have a look at the PR #1439. I think it will exactly do what you need.

A simple K8s configMap could look like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: myscript
data:
  poststart.sh: |
    sleep 30
    rabbitmqctl add_user test test
    rabbitmqctl set_permissions test ".*" ".*" ".*"

Add postStartScriptConfig: myscript to your values.yaml and it should be executed during startup phase.
Pay attention to the sleep command in the first line. The postStart lifecycle will be executed directly when the RabbitMQ container is starting, which means RabbitMQ will not be available at this point in time. It needs a while to boot. I think this can be done better - f.e.: rabbitmq-diagnostics -q check_running in a simple loop.
Anyway, please test, and if it works, I will merge and release this feature.