Startup tasks? #23
Description
Typically more configurable docker images would make use of runparts and a /entrypoint.d/* or /docker-entrypoint.d/ directory, allowing users of a docker image to run pre-flight tasks before launching the images star actor (vault in this case).
Directing users to prefix their entrypoint.d/files with guards that bail early makes the distinction between always runs and only on first run
Obvious candidates for pre-flight tasks might be:
- create collection of known users
- import data
- cancel container startup or continue depending on state of external thing
- notify something
In order to keep the base clean of superflous features, this approach helps image users to customise per scenario without forcing us to create and upload yet-another-image to dockerhub or private registry assuming a circumstances even allow for such a tedious task.
example of how such a thing might work is as follows:
#!/bin/dumb-init /bin/sh
...
shopt -s nullglob
count=${#(/docker-entrypoint.d/*)[@]}
if [[ $count -gt 0 ]]; then
runparts /docker-entrypoint.d/
fi
shopt -u nullglob
exec "$@"