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?

Answer 1

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.