Join our Discord Server
Avinash Bendigeri Avinash is a developer-turned Technical writer skilled in core content creation. He has an excellent track record of blogging in areas like Docker, Kubernetes, IoT and AI.

Docker ENTRYPOINT and CMD : Differences & Examples

2 min read

Docker revolutionized the way we package and deploy applications, allowing developers to encapsulate their software into portable containers. Two critical Dockerfile instructions, ENTRYPOINT and CMD, play a pivotal role in defining how a container behaves when it starts. In this blog post, we’ll delve into the differences between these instructions and provide illustrative examples to guide you in their proper use.

Understanding ENTRYPOINT

The ENTRYPOINT instruction in a Dockerfile defines the main process that will be executed when the container starts. It sets the primary command that runs within the container. For instance:

FROM alpine:latest ENTRYPOINT ["/usr/bin/example-app"]

In this example, the container will run the command /usr/bin/example-app upon startup. It’s worth noting that a Docker image can have only one ENTRYPOINT instruction, and if repeated, the last one takes precedence.

Unraveling CMD

On the other hand, the CMD instruction in a Dockerfile supplies default arguments for the command specified by the ENTRYPOINT. Let’s look at a concise example:

FROM alpine:latest ENTRYPOINT ["/usr/bin/example-app"] CMD ["help"]

Here, the default arguments for the example-app command are set to “help.” This means that if a user runs a container without providing any additional arguments, it will execute /usr/bin/example-app help.

The Key Differences

To encapsulate the differences succinctly:

  • ENTRYPOINT: Defines the main process to be executed inside the container.
  • CMD: Specifies default arguments for the command defined by ENTRYPOINT.

Examples in Action

Example 1 – Using Docker ENTRYPOINT Alone

Consider the following Dockerfile:

FROM alpine:latest ENTRYPOINT ["ls"]

Build the image with:

$ docker build -t entrypoint-demo:latest .

Now, start a container:

$ docker run entrypoint-demo:latest

This container will execute the ls command by default. You can pass additional arguments directly:

$ docker run entrypoint-demo:latest -alh

This versatility showcases how users don’t need to know the container’s binary or its location.

Example 2 – Using Docker CMD Alone

Switching gears, consider a Dockerfile with CMD but no ENTRYPOINT:

FROM alpine:latest CMD ["ls"]

Building and running the image:

$ docker build -t cmd-demo:latest . $ docker run cmd-demo:latest

In this case, the CMD of ls is appended to the default ENTRYPOINT (/bin/sh -c). Attempting to pass arguments directly to ls via docker run will result in an error.

Example 3 – Using ENTRYPOINT and CMD Together

Combining both instructions in a Dockerfile:

FROM alpine:latest ENTRYPOINT ["ls"] CMD ["-alh"]

Build and run the image:

$ docker build -t entrypoint-cmd-demo:latest . $ docker run entrypoint-cmd-demo:latest

This time, the ls command (ENTRYPOINT) is automatically called with the -alh argument (CMD). Users can still supply custom arguments by overriding CMD with docker run.

When to Choose ENTRYPOINT vs CMD

In your Dockerfile, it’s essential to set both ENTRYPOINT and CMD judiciously:

  • ENTRYPOINT: Specify the path to the process to be executed inside the container.
  • CMD: Define the default arguments for that command.

Incorrectly setting CMD instead of ENTRYPOINT is a common pitfall. While your image might still work, users won’t be able to pass arguments directly using docker run. They would need to provide the full path to the binary instead.

In conclusion, the distinction between ENTRYPOINT and CMD contributes to the flexibility of Docker container images. It simplifies the containerization of command-line applications, making it easier for users to interact with your images while preserving the underlying structure.

By understanding these Dockerfile instructions and their nuances, you’ll be better equipped to create efficient and user-friendly containerized applications.

Happy Dockering!

Keep Reading

Please follow and like us:

Have Queries? Join

Avinash Bendigeri Avinash is a developer-turned Technical writer skilled in core content creation. He has an excellent track record of blogging in areas like Docker, Kubernetes, IoT and AI.

This website uses cookies. By continuing to use this site, you accept our use of cookies. 

Join our Discord Server