Supervisor as a way to run multiple entrypoints for my container

Question

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?

score 1 · Answer 1 · answered Mar 03 '21 at 19:37

My script creates a json file from the passed in deployment environment variables for my SPA app to use as configuration.

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):

#!/bin/sh
/app/build-config-json -o /etc/nginx/config.json # or whatever
# --more--

My container is based on the Nginx container ... and the Nginx container already has [an ENTRYPOINT]

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 instead

# ... the rest of the first-time setup ...
exec /docker-entrypoint.sh "$@"

In your Dockerfile you can specify your new ENTRYPOINT, but when you do you need to repeat the original CMD as well. That means this approach generally requires some knowledge of the underlying image; its Dockerfile is ideal but you can find the ENTRYPOINT and CMD from docker history or docker inspect.

ENTRYPOINT ["/wrapped-entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]

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.

score 1 · Accepted Answer · answered Mar 03 '21 at 19:43

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.

If you look at the Dockerfile you link to, that launches a docker-entrypoint.sh script as the ENTRYPOINT. That script is in the same directory in the same GitHub repository, and runs

find "/docker-entrypoint.d/" -follow -type f -print | sort -n | while read -r f; do
    case "$f" in
        *.sh)
            if [ -x "$f" ]; then
                echo >&3 "$0: Launching $f";
                "$f"
            ...
            fi
            ;;
    esac
done

So, 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 existing ENTRYPOINT will run it for you at container startup time; you don't have to override anything.

FROM nginx:1.19
COPY build-config-json /docker-entrypoint.d/30-build-config-json.sh
RUN chmod +x /docker-entrypoint.d/30-build-config-json.sh
# End of file

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.

Supervisor as a way to run multiple entrypoints for my container

2 Answers2