Add /docker-entrypoint-initdb.d customization hooks

[c0deaddict]

Add customization hooks like in the postgres docker (lines are actually from that Dockerfile). This allows for extending the official rabbitmq image without having to copy and refine the whole docker-entrypoint.sh. It could be used for example to configure additional plugins.

[raphink]

Why not test -e and let users choose the language they want to use?

[md5]

Do you mean -x for testing executable status?

The *.sh case is sourcing the script, not just executing it, so it can actually affect the surrounding environment.

[md5]

Besides that, it's pretty easy to call out to an interpreter of your choice from a *.sh script.

[raphink]

Ah right, my bad. I didn't see you were sourcing the script, not executing it.

[c0deaddict]

@md5 Is the sourcing a problem? I guess that the script could affect the environment is a good thing? More power to extend the base docker?

[md5]

@c0deaddict I think the sourcing can be useful, provided the underlying command uses environment variables directly.

[tianon]

Hmm, I'm a little confused on this one -- what makes this different from having your own Dockerfile and using automated builds and repository links (or a similar setup) to keep it up to date? In the case of postgres, there are certain things that can only be accomplished while the server is running.

[c0deaddict]

@tianon The reason I want these changes in the docker image is that I want to make a RabbitMQ docker image with some extra plugins installed (like STOMP and MQTT).

Installing plugins can be done by extending the rabbitmq base image. But what about adding some configuration for the plugin based on the environment variables. The configuration is build in docker-entrypoint.sh and currently there is no way to extend it. So I would have to copy and paste the docker-entrypoint.sh and make my modifications there. Wouldn't it be nicer if anyone can add their own scripts that add something to the rabbitmq.config?

Thinking about this made me realize that the location of the for loop is not correct. The loop should be before the rabbitmq.config file is finalized. I guess something like this would work (from line 112):

        fi

        echo
        for f in /docker-entrypoint-initdb.d/*; do
            case "$f" in
                *.sh)  echo "$0: running $f"; . "$f" ;;
                *)     echo "$0: ignoring $f" ;;
            esac
            echo
        done

        cat >> /etc/rabbitmq/rabbitmq.config <<-'EOF'

Then for example one could add some plugin specific config with:

FROM rabbitmq
RUN rabbitmq-plugins enable --offline rabbitmq_stomp
ADD stomp.sh /docker-entrypoint-initdb.d/

stomp.sh

#!/bin/bash
cat >> /etc/rabbitmq/rabbitmq.config <<-'EOF'
    {rabbitmq_stomp, [{tcp_listeners, [12345]}]}
EOF

What do you think about this?

[yosifkit]

ping @tianon

[tianon]

Ah, yeah, I suppose using this to enable custom additions to the config does make some sense, but I am still concerned that it's different from the way mysql and postgres use this directory (as in, over there, the daemon is explicitly running during the execution of these scripts, and from issues like #38 it seems like that might be a useful thing here too, but I don't know).

[jippi]

Did this PR stall? :(

[yosifkit]

Finally getting back to this old issue and feel like my response is basically the same as docker-library/elasticsearch#86 (comment).

The reason I bring this up is that docker-entrypoint-initdb.d exists in images like postgres to let you do things that can only be done after the database files are initialized and while the database is running. Whereas I don't see that in this PR, since elasticsearch is not running and doesn't require initialization.