What Is a Docker ENTRYPOINT?
Learn what Docker's ENTRYPOINT instruction does, how it differs from CMD, exec vs shell form, and why it matters for graceful signal handling.
Expected Interview Answer
ENTRYPOINT is a Dockerfile instruction that fixes the main executable a container always runs, so the container behaves like a dedicated command rather than an arbitrary shell.
When ENTRYPOINT is set, any CMD value or arguments passed on `docker run` are appended to it as arguments, instead of replacing the whole command the way CMD alone would. This makes ENTRYPOINT useful for building images that behave like a single-purpose CLI tool, where users only need to supply options, not the base command itself. ENTRYPOINT can be defined in exec form, `["executable", "arg"]`, which runs directly without a shell and properly forwards signals like SIGTERM, or in shell form, which wraps the command in `/bin/sh -c` and can swallow signals.
- Locks the container to a single, predictable main process
- Lets CMD supply default arguments that users can override
- Exec form forwards OS signals correctly for graceful shutdown
- Enables images that behave like installable CLI tools
- Combines with wrapper scripts for setup before the main process
AI Mentor Explanation
An ENTRYPOINT is like a bowler's fixed run-up and delivery action that never changes over after over, while the specific line, length, or field placing called before each ball is like the CMD arguments layered on top. A captain can call for a different field setting each delivery, but the bowler's core action stays the same. Change the bowler entirely and you get a completely different ENTRYPOINT.
Step-by-Step Explanation
Step 1
Define ENTRYPOINT in exec form
Write it as a JSON array, e.g. ENTRYPOINT ["myapp"], so it runs directly without a wrapping shell.
Step 2
Optionally add CMD for defaults
CMD supplies default arguments appended after ENTRYPOINT when no override is given at runtime.
Step 3
Override at runtime
Arguments passed to docker run after the image name replace CMD but are still appended to ENTRYPOINT.
Step 4
Signals are forwarded
In exec form, ENTRYPOINT runs as PID 1 and receives signals like SIGTERM directly for graceful shutdown.
Step 5
Combine with a wrapper script
A shell script can be set as ENTRYPOINT to run setup steps before executing exec "$@" to hand off to the real process.
What Interviewer Expects
- Explains that ENTRYPOINT fixes the main command while CMD supplies default arguments
- Knows the difference between exec form and shell form
- Understands how docker run arguments interact with ENTRYPOINT and CMD
- Can explain why exec form is preferred for proper signal handling
- Describes the wrapper-script pattern for setup before the main process
Common Mistakes
- Believing ENTRYPOINT and CMD do the same thing
- Using shell form and being surprised that SIGTERM is not received by the app
- Assuming docker run arguments always replace ENTRYPOINT entirely
- Forgetting to use exec "$@" in a wrapper script, breaking signal forwarding
Best Answer (HR Friendly)
“ENTRYPOINT is a setting in a Docker image that fixes the main program a container will always run, similar to how an appliance is designed for one core purpose even though you can adjust its settings. This makes the container behave predictably, like a dedicated tool rather than a general-purpose computer.”
Code Example
FROM alpine:3.19
COPY greet.sh /usr/local/bin/greet
RUN chmod +x /usr/local/bin/greet
ENTRYPOINT ["greet"]
CMD ["world"]
# docker run myimage -> runs: greet world
# docker run myimage everyone -> runs: greet everyoneFollow-up Questions
- What is the difference between ENTRYPOINT and CMD?
- Why does exec form handle signals better than shell form?
- How do docker run arguments interact with ENTRYPOINT?
- What is the exec "$@" pattern used for in entrypoint scripts?
- Can ENTRYPOINT be overridden at runtime, and how?
MCQ Practice
1. What does ENTRYPOINT define in a Dockerfile?
ENTRYPOINT fixes the main command a container runs, with CMD or runtime arguments appended to it.
2. How do arguments passed to `docker run image arg1` interact with a set ENTRYPOINT?
When ENTRYPOINT is set, extra docker run arguments are appended to it rather than replacing it.
3. Why is exec form, e.g. ENTRYPOINT ["app"], generally preferred over shell form?
Exec form runs the process directly as PID 1 without a wrapping shell, so it correctly receives signals for graceful shutdown.
Flash Cards
What does ENTRYPOINT do? — Fixes the main executable a container always runs.
How do CMD and docker run arguments relate to ENTRYPOINT? — They are appended to ENTRYPOINT as arguments rather than replacing it.
Why prefer exec form for ENTRYPOINT? — It runs as PID 1 and forwards signals like SIGTERM correctly.
What is the exec "$@" pattern for? — Used in wrapper scripts to hand off execution to the real process after setup, preserving PID 1 and signals.