Investigate our coupling to RabbitMQ Community docker entry point script

[Zerpet]

Problem statement

We rely on some behaviour implemented in RabbitMQ Community Docker entry point script. One example is the templating of the default username and password via environment variables e.g. RABBITMQ_DEFAULT_PASS_FILE. By relying on this script, we (and any user) are unable to switch to a different RabbitMQ docker image.

Expected outcome

In this issue we will track the investigation to determine how much and on what points we rely on the docker entry point script, and propose changes to address this coupling. If the changes required are small enough, they can be implemented as part of this issue.

[gerhard]

FWIW, the Docker entry point script will be going away: docker-library/rabbitmq#424

This is how we handle the default user in the "other" RabbitMQ Docker image. There is a related TODO which @coro just reminded me to follow-up on. Thanks 👍🏻

[coro]

I've investigated the entrypoint script, and the only behaviour we rely on from it is the default user/password configuration. It should be fairly simple to transition this to a mounted configMap/.conf file, and so I'll do this as part of this issue.

[gerhard]

It would be great for the public RabbitMQ Docker image to have the same behaviour. Is this potential PR to https://github.com/docker-library/rabbitmq/ in scope?

For more context, read why now is a great time to start breaking down docker-entrypoint.sh functionality into sysctl config fragments: docker-library/rabbitmq#422 (comment)

A separate but somewhat related functionality that will require a different approach to using env vars in the Docker image: rabbitmq/rabbitmq-cli#443. Hint: --erlang-cookie

cc @tianon @michaelklishin

[Zerpet]

The PR for this issue will very likely be specific to the Operator and Kubernetes. That doesn't mean that we can't consider a contribution to the public RabbitMQ Docker image with our learning from this issue 😄

[coro]

The PR for this issue will very likely be specific to the Operator and Kubernetes. That doesn't mean that we can't consider a contribution to the public RabbitMQ Docker image with our learning from this issue 😄

On it: docker-library/rabbitmq#440

Tried to keep it as consistent as possible across the two repos (i.e. credentials in /etc/rabbitmq/conf.d/default_user.conf, as is the case in the commercial RMQ image)