4.2.7.3 ENTRYPOINT Scripts
A focused guide to ENTRYPOINT Scripts, connecting core concepts with practical Docker and container operations.
ENTRYPOINT scripts are custom shell scripts used as a container's ENTRYPOINT, performing setup logic — waiting for a dependency to become available, generating configuration from environment variables, fixing file permissions — before finally launching the actual application.
A Typical Entrypoint Script
An entrypoint script is copied into the image and set as the ENTRYPOINT, with the actual application invocation happening at the end of the script, typically using exec so the application replaces the script process rather than running as its child.
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["python", "app.py"]
#!/bin/sh
set -e
until pg_isready -h "$DB_HOST"; do
echo "Waiting for database..."
sleep 1
done
exec "$@"
This script waits for a database to become reachable before finally executing whatever command was supplied as CMD or overridden at run time.
Why exec Matters in Entrypoint Scripts
Using exec "$@" at the end of the script replaces the shell process with the application process entirely, which is important for correct signal handling — without it, the shell would remain the container's main process, potentially interfering with how termination signals reach the actual application.
exec "$@"
"$@"
The first form ensures the application becomes PID 1 and receives signals directly; the second leaves the shell as the parent process, which can delay or prevent proper signal delivery.
Generating Configuration at Startup
Entrypoint scripts are also commonly used to generate configuration files from environment variables at container startup, since some applications expect configuration as a file rather than as environment variables directly.
envsubst < /app/config.template > /app/config.yaml
exec "$@"
Why Entrypoint Scripts Matter
Entrypoint scripts provide a flexible place to perform necessary startup logic that cannot be expressed through Dockerfile instructions alone, bridging the gap between a static image definition and the dynamic conditions present whenever a specific container actually starts.