Support pre-exec startup scripts that execute whenever the container starts

[jpap]

I am using this image with Kubernetes, where I run the server with SSL enabled. My SSL certificates are symlinks in the $PGDATA directory to the mounted secret volume, so the key/cert isn't stored on disk in unencrypted form. I need to ensure these symlinks are valid and permissions set correctly each time the container starts.

This PR solves this by running scripts in the /docker-entrypoint-preexec.d folder every time the container starts, before performing the final exec to start postgres.

This PR also solves #191 and related to #152.

[yosifkit]

The way this is written could just be accomplished with your own script as CMD (or ENTRYPOINT) that can do setup and then ends with exec docker-entrypoint.sh postgres. To handle doing setup after initdb your script could call a script in docker-entrypoint-initdb.d only if the database has been created (if [ -s "$PGDATA/PG_VERSION" ];).

#!/bin/bash set -e if [ -s "$PGDATA/PG_VERSION" ]; then . /docker-entrypoint-initdb.d/always-script.sh fi exec docker-entrypoint.sh postgres

This also won't solve #191, since postgres will not be running when preexec.d scripts are run (and the psql variable doesn't get set anyway).

One of the reasons that we have not added scripts running at other times is that we cannot guarantee that the user or password in the environment is valid.

[jpap]

Hey Joe,

I generally agree with your comments. One further consideration is that I can override the entrypoint and cmd arguments, whilst also mounting in a /docker-entrypoint-preexec.d/*.sh script, without the necessity for creating a derivative Docker image. In Kubernetes, for example, that's easily done in the pod's container configuration.

That is appealing as I can more easily track any upstream updates by simply referring to your official Docker image and without having to roll my own, and without hosting them in a private registry.

The issue of executing .sql files before the database is up in the preexec path remains. Are you open to reconsider this PR with a change that only considers .sh files in that path?

[jpap]

Closing due to inactivity...