Docker revolutionized the way we package and deploy applications, allowing developers to encapsulate their software into portable containers. Two critical Dockerfile instructions,
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.
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.
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
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
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
When to Choose ENTRYPOINT vs CMD
In your Dockerfile, it’s essential to set both
- 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
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.
- How to setup Ollama with Ollama-WebUI
- How to Run Ollama with Docker Desktop and Kubernetes: A Step-by-Step Guide
- SonarQube Integration with Docker Scout: Ensuring Code Quality for Docker Images
- Secure Coding Essentials for SAP Business Systems
- Why Ollama is Crucial for Docker GenAI Stack?