How do RUN , CMD , and ENTRYPOINT instructions differ in a Dockerfile , and how do they affect container execution ?Question For: Senior Level Developer

Understanding the distinct roles of RUN, CMD, and ENTRYPOINT is fundamental for any senior developer working with Docker. These three instructions, while seemingly similar, operate at different stages of the Docker lifecycle—image build versus container runtime—and offer varying degrees of control and flexibility over your container’s execution.

Direct Summary: RUN vs. CMD vs. ENTRYPOINT

• RUN: Executes commands during the image build process. Each RUN instruction creates a new, read-only layer in the image. It’s used for installing packages, configuring the environment, or compiling applications.
• CMD: Sets a default command and/or arguments for the container at runtime. This default can be easily overridden by specifying a command when running the container with docker run.
• ENTRYPOINT: Defines the main command or executable that will always run when the container starts. Arguments provided during docker run are appended to the ENTRYPOINT command, making it ideal for creating executable containers.

Detailed Breakdown of Each Instruction

1. The RUN Instruction: Building Image Layers

The RUN instruction is executed during the image build process. Its primary purpose is to execute commands that install software, create files, compile code, or configure the image’s environment. Each RUN instruction in a Dockerfile creates a new, read-only layer on top of the previous one.

• Layered Nature: This layered approach is a core concept in Docker. When you modify a RUN instruction, only that specific layer and subsequent layers need to be rebuilt, thanks to Docker’s caching mechanism. This significantly speeds up iterative builds.
• Purpose: Use RUN for any command that needs to persist in the image, such as installing dependencies (e.g., apt-get update && apt-get install -y git) or creating directories.
• Best Practice: Chain multiple commands into a single RUN instruction using && to minimize the number of layers and reduce image size (e.g., RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*).

2. The CMD Instruction: Providing Defaults

The CMD instruction provides a default command or arguments that will be executed when a container starts. It’s designed to be easily overridden at runtime.

• Easily Overridden: If you specify a command when running the container (e.g., docker run <image_name> bash), that command will completely replace the CMD instruction defined in the Dockerfile.
• Purpose: Use CMD to define the default application or service that the container intends to run. For example, a Node.js application might have CMD ["npm", "start"].
• Formats:
  • Exec form (recommended): CMD ["executable", "param1", "param2"]. This is the preferred form as it’s parsed as a JSON array and runs the command directly without invoking a shell.
  • Shell form: CMD command param1 param2. This form executes the command in a shell (e.g., /bin/sh -c), which can be useful for simple commands that require shell features like environment variable substitution.
• Singular Use: Only the last CMD instruction in a Dockerfile will take effect if multiple are present.

3. The ENTRYPOINT Instruction: Setting the Main Command

The ENTRYPOINT instruction defines the main executable that will always run when the container starts. Unlike CMD, arguments provided during docker run are appended to the ENTRYPOINT command, not replaced.

• Ensures Specific Application Runs: ENTRYPOINT ensures that a specific application or script is always executed as the container’s primary process. This is ideal for creating containers that behave like executables.
• Arguments Appended: If your ENTRYPOINT is ["/usr/bin/python3", "my_script.py"] and you run docker run <image_name> arg1 arg2, the command executed inside the container will be /usr/bin/python3 my_script.py arg1 arg2.
• Overriding: While ENTRYPOINT is designed to be less easily overridden than CMD, you can still change it at runtime using the --entrypoint flag with docker run (e.g., docker run --entrypoint bash <image_name>).
• Formats: Similar to CMD, ENTRYPOINT also has exec form (recommended) and shell form.

Combining CMD and ENTRYPOINT for Flexibility

The most powerful use case for CMD and ENTRYPOINT is when they are combined. In this scenario, ENTRYPOINT defines the fixed executable, and CMD provides default arguments to that executable.

• ENTRYPOINT (Exec Form) + CMD (Exec Form): When both are in exec form, the CMD arguments are appended to the ENTRYPOINT command.

  ENTRYPOINT ["nginx"]
  CMD ["-g", "daemon off;"]

  If you run docker run <image_name>, the command executed is nginx -g "daemon off;".
  If you run docker run <image_name> -v, the command executed is nginx -v (the -v overrides the CMD).

• Practical Example: Consider a web application container.

  # Dockerfile
  ENTRYPOINT ["/app/start.sh"]
  CMD ["--config", "/etc/app/default.conf"]

  Here, /app/start.sh is a script that might handle environment setup, logging, and then finally execute the main application. CMD provides the default configuration file.

  • Run with default config: docker run my_web_app (executes /app/start.sh --config /etc/app/default.conf)
  • Run with custom config: docker run my_web_app --config /my/custom/config.conf (executes /app/start.sh --config /my/custom/config.conf)

  This pattern creates highly flexible and reusable container images.

Overriding Behavior: CMD vs. ENTRYPOINT

Understanding how to override these instructions at runtime is crucial for debugging and adapting containers.

• Overriding CMD: This is straightforward. Simply pass a command as an argument to docker run.

  # Dockerfile
  CMD ["echo", "Hello, Docker!"]
  
  # Runtime
  docker run my_image        # Executes: echo Hello, Docker!
  docker run my_image bash   # Executes: bash (overrides CMD)

• Overriding ENTRYPOINT: Requires the --entrypoint flag with docker run. This explicitly changes the primary executable for that specific container instance.

  # Dockerfile
  ENTRYPOINT ["ping"]
  CMD ["google.com"]
  
  # Runtime
  docker run my_image             # Executes: ping google.com
  docker run my_image 8.8.8.8     # Executes: ping 8.8.8.8 (8.8.8.8 overrides CMD)
  docker run --entrypoint bash my_image # Executes: bash (overrides ENTRYPOINT)

  This provides a strong guarantee that the container’s primary function remains consistent unless explicitly overridden.

Key Differences and Scenarios

The most important distinction lies in when and how these instructions affect the container lifecycle:

Instruction	Execution Stage	Purpose	Override Behavior
RUN	Image Build Time	Execute commands to build/configure the image (e.g., install software, create files). Creates new layers.	Cannot be overridden at runtime. Requires rebuilding the image.
CMD	Container Runtime	Provide default command/arguments for the container.	Easily overridden by arguments passed to docker run.
ENTRYPOINT	Container Runtime	Define the main executable for the container. Arguments from docker run are appended.	Overridden explicitly using docker run --entrypoint flag.

For senior developers, leveraging these instructions effectively means designing images that are robust, flexible, and efficient. Choosing the right instruction for the job ensures your containers behave predictably, are easy to use, and can be customized when needed without unnecessary image rebuilds.

Code Sample: Illustrating RUN, CMD, and ENTRYPOINT

Let’s create a simple Dockerfile and demonstrate how these instructions behave.

Dockerfile: myapp/Dockerfile

# Use a lightweight base image
FROM alpine:latest

# RUN instruction: Install curl during image build
RUN apk add --no-cache curl

# ENTRYPOINT instruction: Define the main executable
ENTRYPOINT ["curl", "-s"]

# CMD instruction: Provide default arguments to ENTRYPOINT
CMD ["https://example.com"]

# Add a RUN instruction after CMD/ENTRYPOINT to show build order
RUN echo "Image build complete!" > /tmp/build_status.txt

Build the Image

docker build -t my-curl-app ./myapp

Run the Container and Observe Behavior

1. Running with default CMD:

docker run my-curl-app

Expected Output: The HTML content of https://example.com will be printed, because ENTRYPOINT ["curl", "-s"] combines with CMD ["https://example.com"] to execute curl -s https://example.com.

2. Overriding CMD arguments:

docker run my-curl-app https://google.com

Expected Output: The HTML content of https://google.com will be printed. The argument https://google.com overrides the default CMD arguments and is appended to the ENTRYPOINT, resulting in curl -s https://google.com.

3. Overriding ENTRYPOINT:

docker run --entrypoint sh my-curl-app

Expected Output: You will get a shell prompt inside the container. The --entrypoint sh completely replaces the curl -s entrypoint, and the default CMD (https://example.com) is ignored because sh doesn’t use it as an argument.

4. Observing RUN‘s effect (during build):

docker run my-curl-app cat /tmp/build_status.txt

Expected Output: Image build complete!. This demonstrates that the file created by the final RUN instruction is part of the image and accessible at runtime, while the CMD instruction is overridden by cat /tmp/build_status.txt, which becomes the command executed by ENTRYPOINT (i.e., curl -s cat /tmp/build_status.txt, which will likely error out as curl expects a URL). A better example to show `RUN`’s effect would be to simply run `docker run –entrypoint cat my-curl-app /tmp/build_status.txt` to directly execute `cat` on the file, showing it exists from the build process.

Corrected RUN observation:

docker run --entrypoint cat my-curl-app /tmp/build_status.txt

Expected Output: Image build complete!. This more clearly shows that the file created by the RUN instruction during the build process is indeed present in the final image.