Skip to content
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

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

Closed
wants to merge 1 commit into from

Conversation

jpap
Copy link

@jpap jpap commented Feb 28, 2017

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
Copy link
Member

yosifkit commented Mar 1, 2017

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
Copy link
Author

jpap commented Mar 9, 2017

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
Copy link
Author

jpap commented May 13, 2017

Closing due to inactivity...

@jpap jpap closed this May 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants