Skip to content

Feature Request: Allow definition files to be supplied as ENV var for docker / kubernetes environment #2465

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sspieker-cc opened this issue Oct 8, 2020 · 7 comments
Labels

Comments

@sspieker-cc
Copy link

I have an application that already utilizes RabbitMQ 3.8.9 and has its own methods of configuration. I would like to extend this configuration utilizing an exported definitions.json file so that the same configuration is restored when the container(s) are restarted.

Currently it seems that the only way to provide this information is in the form of the rabbitmq.conf file using:
load_definitions = /path/to/definitions/file.json

Mounting the .conf file from a kubernetes secret causes this file to be read-only and therefore ignored and causing the container to eventually fail to start. If the load_definitions parameter could be supplied as an environment variable, the behavior of the read-only file would be avoided entirely.

Rolling a 'custom' rabbitmq image would be a possible solution however, upgrades to the application that currently utilize rabbitmq-management would need to be managed by hand and it is fraught with all of the dangers that a manual process includes. It seems that the environment variable option would be a good and possible solution that should work rather well.

@sspieker-cc
Copy link
Author

Are there possibly any workarounds that could be utilized in order to either:

  1. append the load_definitions statement to the existing conf file at startup
  2. a different behavior to allow for the definitions to be loaded using RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS env var?

@lukebakken
Copy link
Collaborator

Mounting the .conf file from a kubernetes secret causes this file to be read-only and therefore ignored and causing the container to eventually fail to start.

I don't understand this statement. rabbitmq.conf can be on a read-only file system.

Can you provide exact instructions to reproduce your issue?

@michaelklishin
Copy link
Collaborator

We will not be adding more environment variables. It is perfectly possible to import definitions on Kubernetes.

Our long terms strategy is to depend less and less on environment variables where possible. They are inferior to using a config file with a well known format in almost every way: they do not support value type definitions or validations, for example. rabbitmq.conf fields do.

The same direction was undertaken by the Docker image: a lot of awful hacks that stem from heavy environment variable use are slowly being removed.

RabbitMQ supports a directory of configuration files, so one file can be mounted as read only and new ones generated next to it at deployment time.

The only case where we would add support for more environment variables is when something cannot be configured any other way for the vast majority of users (e.g. a config file or directory location).

@michaelklishin
Copy link
Collaborator

So there are several ways of importing definitions:

  • At boot time via rabbitmq.conf or one of the conf.d files
  • At boot time via advanced.config (you will lose path validations)
  • After node boot using CLI tools or HTTP API

It's also possible to configure the same setting advanced.config would use using Erlang VM arguments but there's almost never any need in doing so. We don't see any need for even more options.

@sspieker-cc
Copy link
Author

Are there any additional examples of how these operations can be applied? Are there practical examples of how to utilize the conf.d directory?

The goal here is to use the stock container with the definitions.json and rabbitmq.conf (or more importantly just the load_definitions configuration directive) to the stock container. The addition of the rabbitmq.conf file through the use of a secret is failing the 'touch' behavior at startup.

Thanks,
Scott

@lukebakken
Copy link
Collaborator

The addition of the rabbitmq.conf file through the use of a secret is failing the 'touch' behavior at startup.

What does the "use of a secret" actually do, what is the "touch behavior", and what is the exact failure?

@michaelklishin
Copy link
Collaborator

@sspieker-cc RabbitMQ Docker image uses the .conf.d approach to load definitions as of docker-library/rabbitmq#430. I'm not sure what you mean by "these operations" but there is a dedicated doc guide on definitions which provides a reasonable number of examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants