Support /docker-entrypoint-init.d/ to customise configuration of image on first start

[dwt]

I have some custom settings that I need to set, and would like to thus customise the setup routine of the docker container.

Currently it runs some form of icinga2 node wizard, which can be customised a bit by setting some environment variables. However having a directory, where you can bind mount your own scripts into and have them start before / after the included initialisation script as needed would be much more powerful.

One of the best examples of how this can be done is - I think - the mariadb image: https://hub.docker.com/_/mariadb (see 'initialising a fresh image').

What do you think?

[kenroyandfamily]

icinga2 startup shows:
"Checking in existing certificates for common name 'icinga-master'"
If the script can't find a cert then it runs the wizard.
So I created a cert named 'icinga-master.crt' and put it in a directory that I then mount to "/data-init/var/lib/icinga2/certs"
Now the setup script is not run and my config files are not overwritten.

[julianbrost]

The suggestion I wrote down in #45 (comment) is somewhat related to this.

@dwt Does your use-case explicitly require running scripts, or would being able to provide extra config files to the container also work for you?

[dwt]

This was quite some time ago, as far as I remember I just gave up and documented a manual step that needs to be taken.

My memory tells me that this needed a script to execute, so a configuration would not have sufficed.

I would classify it like this: having an exec.d/* folder where you can put arbitrary scripts will always be the most powerful, as it gives you full control, to e.g. copy some files from a docker mount, put them somewhere where you can chmod them and thus work around dockers inability to define the owner of mounted folders. Or just do whatever you want.

mariadb - if I remember correctly, does a dual thing, if you put *.sh files in there, it executes them, if you put *.sql files, they are sourced.

Dependending on what implementation constraints you have, I would try to define mariadb as kind of a gold standard and then look how I can work towards that, maybe allow just configuration to be sourced first, and then later allow scripts too, or start with scripts, and then specialize to also allow configuration later as it is probably easier to use for your users for all use cases these can solve, while still preventing some power users from achieving what they want.