Startup tasks?

[airtonix]

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 "$@"

[bkeroackdsc]

This would be really nice for pre-populating Vault with seed secrets as part of a local development/testing workflow.

[inkblot]

Implemented in #59

[bkeroackdsc]

We ended up implementing a derivative image: https://github.com/dollarshaveclub/vault-dev-docker

[emmaroberts-nbs]

Please can we get an update on this?

There has been a PR open for a while now and wondering whether this is likely to be released soon?

[inkblot]

I ended up doing the same thing as @bkeroackdsc and have been migrating solutions like this with other apps to init containers recently.