ENTRYPOINT vs CMD difference in Docker - Trade-offs & Expert Analysis

Overview - ENTRYPOINT vs CMD difference

What is it?

ENTRYPOINT and CMD are instructions used in Dockerfiles to define what command runs inside a container. ENTRYPOINT sets the main command that always runs, while CMD provides default arguments or a fallback command if none is given. Both control container behavior but serve different roles in how commands are executed.

Why it matters

Without understanding ENTRYPOINT and CMD, you might create containers that don't run as expected or are hard to customize. This can cause confusion when overriding commands or passing arguments, leading to wasted time and errors in deployment. Knowing their difference helps you build flexible and predictable containers.

Where it fits

Before learning ENTRYPOINT and CMD, you should understand basic Docker concepts like images, containers, and Dockerfiles. After mastering these, you can explore advanced container customization, multi-stage builds, and orchestration tools like Kubernetes.

Mental Model

Core Idea

ENTRYPOINT defines the fixed command a container runs, while CMD provides default arguments or a fallback command that can be overridden.

Think of it like...

Think of ENTRYPOINT as the engine of a car that always runs, and CMD as the default destination set on the GPS that you can change anytime.

┌───────────────┐
│   Dockerfile  │
├───────────────┤
│ ENTRYPOINT    │──▶ Fixed command (engine)
│ CMD           │──▶ Default args or fallback (GPS destination)
└───────────────┘
        │
        ▼
┌─────────────────────┐
│ Container Execution  │
│ ENTRYPOINT runs      │
│ CMD provides args    │
└─────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is ENTRYPOINT in Docker

Concept: ENTRYPOINT sets the main command that always runs when a container starts.

In a Dockerfile, ENTRYPOINT specifies the executable that will run inside the container. It is like the container's main program. For example: ENTRYPOINT ["/bin/echo"] This means every time the container runs, it will execute /bin/echo.

Result

The container always runs the specified command, making it behave like a dedicated application.

Understanding ENTRYPOINT helps you fix the container's purpose and ensures it always runs the intended program.

2

Foundation

What is CMD in Docker

Concept: CMD provides default arguments or a fallback command if no command is given when running the container.

CMD sets default parameters or a command to run if the user does not specify one. For example: CMD ["Hello, World!"] If the container's ENTRYPOINT is /bin/echo, CMD provides the text to echo by default.

Result

The container uses CMD as default input or command, but this can be overridden when running the container.

CMD allows flexibility by setting defaults that users can change without modifying the Dockerfile.

3

Intermediate

How ENTRYPOINT and CMD work together

🤔Before reading on: do you think CMD overrides ENTRYPOINT or complements it? Commit to your answer.

Concept: ENTRYPOINT defines the fixed command, and CMD provides default arguments to that command.

When both ENTRYPOINT and CMD are set, Docker runs ENTRYPOINT with CMD as its arguments. For example: ENTRYPOINT ["/bin/echo"] CMD ["Hello"] Running the container executes: /bin/echo Hello If you run the container with extra arguments, those replace CMD arguments.

Result

The container runs the ENTRYPOINT command with CMD as default arguments, allowing easy customization.

Knowing this interaction clarifies how to design flexible containers that have a fixed command but customizable behavior.

4

Intermediate

Overriding CMD and ENTRYPOINT at runtime

🤔Before reading on: can you override ENTRYPOINT by passing arguments to docker run? Commit to yes or no.

Concept: CMD can be overridden by passing arguments to docker run, but ENTRYPOINT can only be overridden with a special flag.

If you run: docker run image "New argument" This replaces CMD arguments but keeps ENTRYPOINT. To override ENTRYPOINT, use: docker run --entrypoint new_command image This replaces ENTRYPOINT entirely.

Result

You can customize container behavior at runtime by overriding CMD easily and ENTRYPOINT with a special flag.

Understanding override rules helps avoid confusion when containers don't behave as expected.

5

Intermediate

ENTRYPOINT forms: exec vs shell

🤔Before reading on: do you think ENTRYPOINT using shell form runs in a shell or directly? Commit to your answer.

Concept: ENTRYPOINT can be written in exec form (array) or shell form (string), affecting how the command runs.

Exec form example: ENTRYPOINT ["/bin/echo", "Hello"] Shell form example: ENTRYPOINT /bin/echo Hello Exec form runs the command directly without a shell, preserving signals and arguments. Shell form runs inside a shell, which can cause issues with signal handling.

Result

Exec form is preferred for predictable behavior and proper signal forwarding.

Knowing the difference prevents subtle bugs in container shutdown and signal handling.

6

Advanced

Why ENTRYPOINT is preferred for fixed commands

🤔Before reading on: do you think CMD alone can enforce a fixed command? Commit to yes or no.

Concept: ENTRYPOINT is used to enforce a fixed command that cannot be accidentally overridden by users, unlike CMD.

Using ENTRYPOINT ensures the container always runs the intended program. CMD only provides defaults and can be replaced by user arguments. For example, a database container uses ENTRYPOINT to start the database server, while CMD sets default options.

Result

Containers behave consistently and securely by fixing the main command with ENTRYPOINT.

Understanding this helps design containers that are both flexible and reliable in production.

7

Expert

Surprising behavior with combined ENTRYPOINT and CMD

🤔Before reading on: do you think CMD arguments are appended or replace ENTRYPOINT arguments? Commit to your answer.

Concept: When ENTRYPOINT and CMD are both arrays, CMD arguments are appended to ENTRYPOINT arguments, but if ENTRYPOINT is a shell form, CMD is ignored.

Example: ENTRYPOINT ["/bin/sh", "-c"] CMD ["echo Hello"] Here, CMD is not ignored because ENTRYPOINT is in exec form, but the combination can cause unexpected behavior because /bin/sh -c expects a single string command. Also, if ENTRYPOINT has arguments, CMD appends to them, which can cause unexpected command lines if not carefully designed.

Result

Misunderstanding this can cause containers to run wrong commands or fail silently.

Knowing this subtlety prevents hard-to-debug container startup issues in complex Dockerfiles.

Under the Hood

Docker combines ENTRYPOINT and CMD during container start by creating the final command line. ENTRYPOINT sets the executable and initial arguments. CMD provides default arguments that are appended or replaced depending on runtime inputs. Docker uses exec form to run commands directly or shell form to run via a shell process, affecting signal handling and process IDs.

Why designed this way?

Docker separates ENTRYPOINT and CMD to balance fixed container behavior with user flexibility. ENTRYPOINT ensures the container runs a specific program, while CMD allows default options that users can override. This design supports both strict application containers and flexible utility containers.

┌───────────────┐
│ Dockerfile    │
│ ENTRYPOINT    │───┐
│ CMD           │───┼──▶ Docker combines to form final command
└───────────────┘   │
                    ▼
           ┌─────────────────────┐
           │ Container runtime    │
           │ Runs ENTRYPOINT +   │
           │ CMD or user args    │
           └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does CMD override ENTRYPOINT if both are set? Commit to yes or no.

Common Belief: CMD always overrides ENTRYPOINT if both are present.

Reality: CMD only provides default arguments to ENTRYPOINT; it does not override the ENTRYPOINT command itself.

Why it matters: Believing CMD overrides ENTRYPOINT leads to unexpected container behavior and confusion when commands don't change as expected.

Quick: Does ENTRYPOINT in shell form handle signals properly? Commit to yes or no.

Common Belief: ENTRYPOINT in shell form behaves the same as exec form and handles signals correctly.

Reality: Shell form runs inside a shell process, which can block signals like SIGTERM, causing issues in container shutdown.

Why it matters: Ignoring this causes containers to hang or not stop gracefully, complicating orchestration and resource cleanup.

Quick: Can you override ENTRYPOINT by passing arguments to docker run? Commit to yes or no.

Common Belief: Passing arguments to docker run replaces ENTRYPOINT.

Reality: Arguments replace CMD, but ENTRYPOINT remains unless overridden explicitly with --entrypoint flag.

Why it matters: Misunderstanding this leads to failed attempts to customize container behavior and wasted debugging time.

Quick: Does CMD run if ENTRYPOINT is not set? Commit to yes or no.

Common Belief: CMD only works if ENTRYPOINT is set.

Reality: CMD runs as the command if ENTRYPOINT is not set, acting as the container's default command.

Why it matters: Not knowing this can cause confusion about why containers run or fail when ENTRYPOINT is missing.

Expert Zone

1

ENTRYPOINT in exec form preserves Unix signals, enabling proper container shutdown and signal forwarding.

2

Combining ENTRYPOINT and CMD allows building containers that are both fixed in purpose and flexible in arguments, a pattern used in official Docker images.

3

Overriding ENTRYPOINT requires explicit flags, which protects containers from accidental command changes but requires awareness when customization is needed.

When NOT to use

Avoid ENTRYPOINT when you want users to fully control the command run by the container; use CMD alone instead. For simple utility containers where flexibility is key, CMD is better. Also, avoid shell form ENTRYPOINT in production due to signal handling issues; prefer exec form.

Production Patterns

In production, ENTRYPOINT is used to fix the main application (e.g., a web server), while CMD sets default options or environment-specific parameters. Multi-stage builds often use ENTRYPOINT to run scripts that prepare the environment before launching the main app.

Connections

Unix process signals

ENTRYPOINT exec form preserves signal handling, unlike shell form which can block signals.

Understanding Unix signals helps explain why exec form ENTRYPOINT is critical for graceful container shutdown.

Command line argument parsing

CMD provides default arguments that are appended to ENTRYPOINT, similar to how programs parse command line inputs.

Knowing how argument parsing works clarifies how CMD and ENTRYPOINT combine to form the final command.

GPS navigation systems

ENTRYPOINT is like the fixed engine of a car, CMD like the default GPS destination that can be changed.

This cross-domain view helps grasp the balance between fixed behavior and flexible inputs in container commands.

Common Pitfalls

#1 Using shell form ENTRYPOINT causes signal handling problems.

Wrong approach:

ENTRYPOINT /bin/sh -c "myapp --option"

Correct approach:

ENTRYPOINT ["/bin/sh", "-c", "myapp --option"]

Root cause:

Shell form runs as a child shell process that does not forward signals properly, causing shutdown issues.

#2 Expecting CMD to override ENTRYPOINT command.

Wrong approach:

ENTRYPOINT ["/bin/echo"]
CMD ["Hello"]

Running: docker run image /bin/date

Expecting /bin/date to run, but /bin/echo runs instead.

Correct approach:

Override ENTRYPOINT explicitly:
docker run --entrypoint /bin/date image

Root cause:

CMD only replaces arguments to ENTRYPOINT, not the ENTRYPOINT command itself.

#3 Not providing CMD when ENTRYPOINT expects arguments.

Wrong approach:

ENTRYPOINT ["/bin/echo"]
# No CMD

Running container results in no output or error.

Correct approach:

Provide CMD with default arguments:
CMD ["Hello World"]

Root cause:

ENTRYPOINT runs but has no arguments, leading to unexpected behavior or no output.

Key Takeaways

ENTRYPOINT sets the fixed command a container runs, ensuring consistent behavior.

CMD provides default arguments or fallback commands that users can override at runtime.

ENTRYPOINT and CMD work together by combining the fixed command with flexible inputs.

Exec form ENTRYPOINT is preferred for proper signal handling and predictable execution.

Understanding how to override ENTRYPOINT and CMD prevents common container customization errors.