Proper Script Execution in Dockerfile: Comparative Analysis of RUN vs ENTRYPOINT

Analysis of Dockerfile Script Execution Mechanism

In Docker containerized deployment processes, proper script execution is a critical component of the build workflow. Based on typical problems encountered in actual development, this article provides an in-depth analysis of two core instructions for script execution in Dockerfile: RUN and ENTRYPOINT.

Execution Principle of RUN Instruction

The RUN instruction creates intermediate containers during the image build phase and executes specified commands, then freezes the execution results into new intermediate images. This means script execution results are permanently preserved in the final image, making it suitable for scenarios requiring persistent configuration.

FROM php:7-fpm
ADD bootstrap.sh /
RUN chmod +x /bootstrap.sh
RUN /bootstrap.sh

The above code demonstrates the standard usage of the RUN instruction. First, the script is added to the image via the ADD command, then execution permissions are granted using RUN chmod +x, and finally the script is executed through RUN /bootstrap.sh. The advantage of this approach is that after build completion, the script execution effects are persisted in the image.

Operation Mechanism of ENTRYPOINT Instruction

Unlike RUN, ENTRYPOINT executes specified commands or scripts when the container starts. This means that every time a container is created based on this image, the script specified by ENTRYPOINT will be executed.

FROM php:7-fpm
ADD bootstrap.sh /
RUN chmod +x /bootstrap.sh
ENTRYPOINT ["/bin/bash", "/bootstrap.sh"]

This configuration method is suitable for scenarios requiring initialization operations each time the container starts, such as environment variable setup and service configuration.

Key Considerations for Script Execution

Ensuring proper script execution requires attention to multiple technical details. First, scripts must have executable permissions, typically achieved through the RUN chmod +x command. Second, scripts should include proper shebang declarations, such as #!/bin/bash or #!/bin/sh, to specify the interpreter.

Cross-platform development also requires attention to line ending issues. Windows systems default to CRLF line endings, while Linux systems use LF. If scripts are edited in Windows environments, conversion to Unix format may be necessary during saving; otherwise, Linux systems might not correctly recognize the shebang.

#!/bin/bash
set -e
# Specific script content
echo "Script executed successfully"

Analysis of Practical Application Scenarios

Consider a specific git configuration scenario. Suppose bootstrap.sh contains git config --global commands that need to modify the .gitconfig file in the user's home directory. In Docker environments, the default user is root, so the configuration file path is /root/.gitconfig.

In this case, using the RUN instruction is more appropriate because git configuration only needs to be executed once during build, with configuration results persisted in the image. After container startup, these configurations can be used directly without repeated execution.

Troubleshooting and Best Practices

When script execution fails, first check script permissions and shebang declarations. Debugging can be performed by entering running containers via docker exec command:

docker exec -it container_name /bin/bash
ls -l /bootstrap.sh  # Check file permissions
cat /bootstrap.sh    # Check file content

Additionally, using the set -e command in scripts is recommended to ensure immediate exit upon encountering errors, facilitating problem identification. For complex scripts, adding detailed log output helps track execution processes.

Comprehensive Comparison and Selection Recommendations

The RUN instruction is suitable for build-time configuration, such as software installation and file compilation that need to be solidified into the image. ENTRYPOINT is more appropriate for runtime initialization, such as service startup and dynamic configuration loading.

In actual projects, both instructions are typically combined: using RUN for basic environment setup and ENTRYPOINT for dynamic configuration during container startup. This layered strategy ensures both build efficiency and flexible runtime control.