I have a need to run a script when my container starts up. (My script creates a json file from the passed in deployment environment variables for my SPA app to use as configuration.) My container is based on the Nginx container.
But a Dockerfile does not allow for more than one ENTRYPOINT and the Nginx container already has one (that I assume I need to keep in there so it will work right.)
I found this question: Docker multiple entrypoints. It’s accepted answer suggests that I use Supervisor to accomplish what I need. I was ready to try that out, but one of the alternate answers just uses a script (which was my plan before I saw this answer). In the comments, this solution (of using a script) has a concern raised. It says:
Supervisor is arguably better, since it can restart your processes if they die, has configurable logging options, can receive commands remotely over RPC, etc.
The reference here to "it can restart your processes if they die" concerns me a bit. I am not sure what that means. I don’t want my script to be re-run once it is done. (It creates the json file at container startup and is not needed after that.)
Will supervisor cause my script to be re-run over and over?
Or am I fine to use supervisor to run both Nginx’s /docker-entrypoint.sh
script and my script? Or should I just chain them together and leave supervisor out of it?
2
Answers
This is straightforward to do in an entrypoint script. You can write a script that does the initial setup, and then launches the main process (there’s a "but" for your particular case):
Normally you’d end the entrypoint script with
exec "$@"
to launch the main container process. In this case, you can launch the original entrypoint script insteadIn your Dockerfile you can specify your new
ENTRYPOINT
, but when you do you need to repeat the originalCMD
as well. That means this approach generally requires some knowledge of the underlying image; its Dockerfile is ideal but you can find theENTRYPOINT
andCMD
fromdocker history
ordocker inspect
.I would avoid supervisord if possible. The options it has around restarting processes and managing logging are things Docker will already do for you. It’s not necessary for just startup-time container initialization.
If you look at the Dockerfile you link to, that launches a
docker-entrypoint.sh
script as theENTRYPOINT
. That script is in the same directory in the same GitHub repository, and runsSo, for this particular base image, if you put your initialization script in
/docker-entrypoint.d
, it’s named*.sh
, and it’s executable, then the existingENTRYPOINT
will run it for you at container startup time; you don’t have to override anything.The default packaging also includes a script that will run
envsubst
on any*.template
file in/etc/nginx/templates
to produce a corresponding config file in/etc/nginx/conf.d
, if that’s what your startup sequence happens to need.