Using Environment Variables in Docker ENTRYPOINT: A Comparison of Exec Form and Shell Form

Fundamentals of Docker ENTRYPOINT and Environment Variables

In Docker containerized applications, the ENTRYPOINT instruction defines the default command to run when a container starts. Based on syntax form, ENTRYPOINT primarily exists in two variants: Exec form and Shell form. Exec form uses a JSON array format to specify the command and its arguments, while Shell form uses a straightforward string format.

Limitations of Environment Variables in Exec Form

When using Exec form ENTRYPOINT, Docker directly executes the specified command without launching a command shell. This means normal shell processing features, including environment variable substitution, will not occur. For example, consider the following Dockerfile configuration:

ENV ADDRESSEE=world
ENTRYPOINT ["./greeting", "--message", "Hello, $ADDRESSEE"]

In this example, $ADDRESSEE will not be replaced with the environment variable's value but will be passed as a literal string to the greeting command. This happens because Exec form directly invokes the executable, bypassing the shell's variable expansion mechanism.

Solution Using Shell Form

The simplest solution to achieve environment variable substitution is to use Shell form ENTRYPOINT. Shell form launches a shell process to handle the command, thereby supporting environment variable substitution and other shell features. The modified configuration looks like this:

ENV ADDRESSEE=world
ENTRYPOINT ./greeting --message "Hello, $ADDRESSEE!"

In this form, the shell performs substitution on $ADDRESSEE before executing the command, ensuring the greeting command receives the correct parameter value.

Executing Shell Commands in Exec Form

If Exec form must be used, environment variable substitution can be achieved by explicitly executing shell commands. Although this approach adds complexity, it offers greater flexibility. Example configuration:

ENV ADDRESSEE=world
ENTRYPOINT ["sh", "-c", "./greeting --message \"Hello, $ADDRESSEE!\""]

Here, we use sh -c to launch a shell process and execute the greeting command within it. The shell handles environment variable substitution, ensuring proper parameter passing.

Practical Applications of Environment Variable Persistence

Environment variable management becomes particularly important in complex development environments. Taking the ESP-IDF development environment as an example, the entrypoint script is responsible for setting numerous environment variables and path configurations. When using docker exec to execute commands, newly created processes do not inherit environment variables set by the entrypoint script because they are different processes.

Solutions include:

• Pre-setting critical environment variables in the Dockerfile
• Re-executing commands through the entrypoint script
• Using docker attach to connect to a pre-configured container terminal

Best Practice Recommendations

Based on practical application experience, we recommend the following best practices:

1. For simple environment variable substitution, prioritize Shell form ENTRYPOINT
2. When precise control over process arguments is needed, use Exec form with explicit shell execution
3. In development environments, design entrypoint scripts carefully to ensure environment variable consistency
4. In production environments, explicitly define all required environment variables in the Dockerfile

Conclusion

Understanding how different forms of Docker ENTRYPOINT handle environment variables is crucial for building reliable containerized applications. By appropriately choosing the ENTRYPOINT form and considering the requirements of specific application scenarios, developers can effectively manage environment variables within containers, ensuring proper application execution. The technical solutions and best practices provided in this article offer practical guidance for Docker users dealing with environment variable challenges.