Override Docker Entrypoint (How to Change CMD & ENTRYPOINT with Examples)

Override Docker Entrypoint (How to Change CMD & ENTRYPOINT with Examples)

What is Docker ENTRYPOINT and Its Purpose?

In Docker, ENTRYPOINT defines the main executable that runs when a container starts. It specifies the command that will always be executed, making it the core behavior of the container.

The primary purpose of ENTRYPOINT is to ensure that a container behaves like a specific application or service. For example, a container built for a web server will always start the web server process when launched.

Unlike CMD, which provides default arguments, ENTRYPOINT enforces the execution of a particular command. This makes it useful when you want to restrict how a container runs or ensure consistent behavior across environments.

Example:

text
ENTRYPOINT ["nginx"]

In this case, every time the container starts, it will run the Nginx server as the main process.

You can still modify or override this behavior at runtime using the --entrypoint flag, especially for debugging or testing purposes.


How to override Docker Entrypoint

You can override the Docker ENTRYPOINT using the --entrypoint flag. The general syntax for using the --entrypoint flag is:

bash
docker run [OPTIONS] --entrypoint [COMMAND/EXECUTABLE] IMAGE [ARG...]

Here,

  • [OPTIONS]: Other docker run flags (e.g., -it, --rm, -d, -e). The --entrypoint option must come before the image name.
  • [COMMAND/EXECUTABLE]: The new command you want to set as the entrypoint (e.g., /bin/bash, sh, ./myscript.sh).
  • IMAGE: The name of the Docker image.
  • [ARG...]: Any arguments you pass after the image name become arguments to this new entrypoint command, overriding any default CMD in the Dockerfile.

Example:

bash
docker run --entrypoint /bin/bash <image_name>

To override only the CMD, simply pass a new command at runtime:

bash
docker run <image_name> <new_command>

You can also explore interactive execution using docker run -i for better control over container behavior.


Quick Command Reference

TaskCommand
Override CMDdocker run <image> <new_command>
Override ENTRYPOINTdocker run --entrypoint /bin/bash <image>
Run interactive containerdocker run -it <image> bash
Override ENTRYPOINT + CMDdocker run --entrypoint <cmd> <image> <args>

Understanding ENTRYPOINT vs CMD (Core Concept)

  • ENTRYPOINT defines the main executable that always runs
  • CMD provides default arguments to ENTRYPOINT
  • CMD can be overridden easily at runtime
  • ENTRYPOINT requires --entrypoint flag to override

When Docker uses ENTRYPOINT vs CMD

Docker combines ENTRYPOINT and CMD when running a container:

  • ENTRYPOINT acts as the base command
  • CMD is appended as arguments

Example:

bash
ENTRYPOINT ["echo"]
CMD ["Hello"]

Running the container results in:

bash
echo Hello

If you override CMD:

bash
docker run <image> Hi

Output becomes:

bash
echo Hi

Common Ways to Override Entrypoint

Method 1: Override CMD (pass arguments at runtime)

You can override the CMD instruction by passing a new command:

bash
docker run <image_name> <new_command>

This is useful when you want to change arguments without modifying the image.

Method 2: Override ENTRYPOINT using --entrypoint

To replace the default executable entirely:

bash
docker run --entrypoint /bin/bash <image_name>

This is commonly used for debugging or running custom commands. If your container exits immediately after override, refer to keep docker container running.

Method 3: Run container in interactive shell (debugging use case)

Run the container in interactive mode:

bash
docker run -it --entrypoint /bin/bash <image_name>

This allows you to explore the container environment and troubleshoot issues. You can also inspect logs using docker logs if needed.


Common Issues and Troubleshooting

CMD not getting overridden as expected

If CMD is not overridden, it may be because the image uses ENTRYPOINT, which takes precedence. In such cases, CMD values are treated as arguments rather than replacing the command.

To fully override execution, use:

bash
docker run --entrypoint <command> <image>

You can review container execution behavior using docker run options.

ENTRYPOINT ignoring runtime arguments

ENTRYPOINT can sometimes ignore runtime arguments if it is defined in exec form and does not accept parameters as expected.

Solution:

  • Verify how ENTRYPOINT is defined in the Dockerfile
  • Use --entrypoint to replace it completely

Container exiting immediately after override

If the container exits after overriding ENTRYPOINT, it usually means the new command has completed execution.

Solution:

  • Use a long-running process like /bin/bash or sleep infinity
  • Run container in interactive mode
bash
docker run -it --entrypoint /bin/bash <image>

For more details on keeping containers alive, refer to keep docker container running.


Frequently Asked Questions

1. How do I override Docker ENTRYPOINT?

You can override Docker ENTRYPOINT using the --entrypoint option with the docker run command.

2. What is the difference between ENTRYPOINT and CMD?

ENTRYPOINT defines the main executable, while CMD provides default arguments that can be overridden at runtime.

3. Can I override CMD without changing ENTRYPOINT?

Yes, you can override CMD by providing a new command at the end of the docker run command.

4. When should I override ENTRYPOINT?

You should override ENTRYPOINT for debugging, testing, or running alternate commands inside a container.

Conclusion

Overriding Docker ENTRYPOINT and CMD provides flexibility to customize container behavior at runtime. By understanding how these instructions work together, you can debug containers, run custom commands, and adapt images without modifying the Dockerfile.

To manage containers effectively, you may also find it useful to
list containers using docker ps and
restart containers when needed.


Official Documentation

For more details, refer to the official Docker documentation:

Docker ENTRYPOINT and CMD documentation

Deepak Prasad

Deepak Prasad

R&D Engineer

Founder of GoLinuxCloud with over a decade of expertise in Linux, Python, Go, Laravel, DevOps, Kubernetes, Git, Shell scripting, OpenShift, AWS, Networking, and Security. With extensive experience, he excels across development, DevOps, networking, and security, delivering robust and efficient solutions for diverse projects.