-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new "docker-ensure-initdb.sh" script #1150
Add new "docker-ensure-initdb.sh" script #1150
Conversation
Im probably using this wrong but it gives me:
I think that's because that variable is defined inside a function in the entrypoint. |
if [ "$#" -eq 0 ] || [ "$1" != 'postgres' ]; then | ||
set -- postgres "$@" | ||
fi | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+declare -g DATABASE_ALREADY_EXISTS=
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's weird - docker_setup_env
already includes declare -g DATABASE_ALREADY_EXISTS
which should make this global even from within a function, and we don't try to read that variable until after we've invoked that function. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OH! I think it's because this new script includes set -u
where the entrypoint is still just # TODO swap to -Eeuo pipefail above (after handling all potentially-unset variables)
, and we don't explicitly set the variable to empty in that function. 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, updated (and re-tested successfully 😇).
Beside the minor code issue, I confirm this meets the use case in #1141 using: services:
db-init:
build:
context: ../alpine3.18
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: example
volumes:
- pgdata:/var/lib/postgresql/data/
user: postgres
command: docker-ensure-initdb.sh |
a9c98df
to
56fba9d
Compare
This mimics the behavior of `docker-entrypoint.sh` before it starts the PostgreSQL server. It has three main goals/uses: 1. (most importantly) as an example of how to use "docker-entrypoint.sh" to extend/reuse the initialization behavior 2. ("docker-ensure-initdb.sh") as a Kubernetes "init container" to ensure the provided database directory is initialized; see also "startup probes" for an alternative solution (no-op if database is already initialized) 3. ("docker-enforce-initdb.sh") as part of CI to ensure the database is fully initialized before use (error if database is already initialized)
56fba9d
to
c86568a
Compare
(rebased for merge conflicts) |
Changes: - docker-library/postgres@31aed10: Merge pull request docker-library/postgres#1150 from infosiftr/docker-ensure-initdb
This mimics the behavior of
docker-entrypoint.sh
before it starts the PostgreSQL server.It has three main goals/uses:
(most importantly) as an example of how to use "docker-entrypoint.sh" to extend/reuse the initialization behavior
("docker-ensure-initdb.sh") as a Kubernetes "init container" to ensure the provided database directory is initialized; see also "startup probes" for an alternative solution (no-op if database is already initialized)
("docker-enforce-initdb.sh") as part of CI to ensure the database is fully initialized before use (error if database is already initialized)
Closes #1141 (alternative to)
Closes #1113
Closes #731
This is something I wrote more than a year ago, but wasn't sure we wanted to actually commit to maintaining over time (and I'm still not 100% sold, but it does seem useful as an example of how to use
docker-entrypoint.sh
correctly, per #496).