Enable web_stomp plugin

[techniq]

Is it possible to enable the web_stomp plugin with this image? It appears to enable to management plugin you must use a specific docker tag(s) (#-management). It would be nice if you could pass an environment variable to declare which plugins you need.

On our current project we've resorted to copying the Dockerfile so we may run rabbitmq-plugins enable rabbitmq_web_stomp, which seems kind of overkill to enable a plugin.

[yosifkit]

Since we already have an entrypoint defined, it is not too far of a stretch to add an ENV var to enable plugins, but then you have a possibly long docker run command. I am leaning toward thinking that having your own docker image with the plugins ready to go would be better than telling operations and your developers that they need to run it with a -e RABBIT_PLUGINS='enable all the plugins that we need'.

[vovimayhem]

@yosifkit I agree on making a Dockerfile instead of telling operations... but I'm not that much into making a new Dockerfile (using a FROM command) when the added functionality is small - like enabling just 1 plugin - and/or can be solved by mounting a volume - I like to stay as official as I can :).

I liked the way the official postgresql docker entrypoint file checks a mountable volume for any extra initialization scripts (see line 49). I've used that for initialization scripts (Adding databases, changing encoding, etc)

Maybe we could do the same in this image? Add initialization scripts into a folder which would - among other things - add & enable plugins, create vhosts, queues, etc.

How do you feel about this? @yosifkit @tianon

[yosifkit]

We do the init scripts directory for the postgres images since the database cannot be initialized until container start. Since these plugins can be enabled beforehand (like in a RUN line), I would be hesitant to add a similar script directory here. I think @tianon may have similar thoughts.

[tianon]

My thoughts exactly 👍

The "initdb" support was added specifically because the functionality provided there can't be duplicated in a Dockerfile easily. In this case, enabling plugins in a Dockerfile is trivial (as seen in https://github.com/docker-library/rabbitmq/blob/5d74f800696dd55614b8c8cdcc142533563f83a1/management/Dockerfile). Combine that with automated builds (https://docs.docker.com/docker-hub/builds/) and repository links (https://docs.docker.com/docker-hub/builds/#repository-links) and it's reasonably easy to have an up-to-date image built FROM this one with extra plugins enabled (and have the "enablement" baked into the image instead of happening at container run time).

[vovimayhem]

Got it!

[techniq]

Fair enough explanation for me. Thanks

[cecchisandrone]

Thanks for the explanation guys!