Introduce a variant without the VOLUME declaration

[HoloRin]

While ideal in most cases, the inclusion of the VOLUME prevents further modification of the RABBITMQ_DATA_DIR by derivative Dockerfiles. This is an attempt at the lightest weight option for maintaining the behavior of the existing images, but providing flexibility when necessary.

[HoloRin]

The Rabbit team would like change the default location of the enabled_plugins file to the $RABBITMQ_DATA_DIR. The motivating factor is that the current location in /etc/rabbitmq/ is often mounted read only in k8s contexts, leading to other difficulties. This would however break the current management images (See rabbitmq/rabbitmq-server#2234 for the extended discussion). Moving the VOLUME declaration to the end of the Dockerfiles via this change would allow us proceed.

[HoloRin]

#368 is another example of read only config files causing difficulties.

[tianon]

Reading through rabbitmq/rabbitmq-server#2234, I'm not exactly convinced this is the correct solution -- there are a lot of good points in that thread, but what strikes me the most is that installing plugins requires not only adding the plugin to enabled_plugins, but also installing the plugin itself, which wouldn't be persistent in most containers (and doesn't get installed to /var/lib/rabbitmq as far as I know).

So I guess I'm not sure I understand completely the use case here -- the only use case I can see which would be helped by these changes is that of an image that's FROM rabbitmq, pre-installs a bunch of plugins, but doesn't enable them, and then expecting users to enable them at runtime? I feel like I'm missing something important.

There are a lot of great points in that thread about configuration vs state that I fully agree with -- state belongs in a VOLUME, configuration does not, but I don't see how shifting the volume choice onto users helps them. 😕

[HoloRin]

@tianon thanks for your comments.

I didn't see this as shifting a volume choice onto users per-sey, which is why all the existing variants retain their VOLUME. If it were possible to have images that were abstract in the sense of the Java keyword, then I would have made the volumeless image one of them.

I think I see the change in this way: We have come to view the enabled_plugins as less so config, and more so seed data. My impression is that seed data is a little tricky in docker (#410 (comment)), but we are balancing that against the difficulty for users that arises when they (not unreasonably) provide enabled_plugins in a read-only fashion. There are some plugins which are helpful to enable at runtime to inspect the system, but not all the time.

Having just made the comparison of enabled_plugins to seed data, it does occur to me that it could probably be built just in time by the docker-entrypoint.sh. If that's considered a substantially superior approach, I could close this an open a new PR to that effect. Another option would be to give the -volumeless variants a special entrypoint that would instruct users not to use it directly, where it would be "runtime abstract".