Container ENTRYPOINT and CMD

`ENTRYPOINT` and `CMD` combine to select a container's default process and arguments. A common service pattern uses an exec-form ENTRYPOINT for the executable and CMD for defaults that runtime arguments can replace.

A container starts a process from its image configuration. `ENTRYPOINT` and `CMD` cooperate to determine that process and its arguments: `ENTRYPOINT` commonly identifies the executable, and `CMD` commonly provides its default arguments.

In exec form, such as `ENTRYPOINT ["python", "-m", "myapp"]`, the values are passed as an argument vector without an implicit shell. If an exec-form `CMD` is also present, its elements are appended as defaults. Arguments supplied after the image name at `docker run` replace the image's `CMD` arguments, while the entrypoint remains in place.

Without an `ENTRYPOINT`, `CMD` can specify the whole default command, for example `CMD ["python", "-m", "myapp"]`. At runtime, a command after the image name replaces that command. Docker's `--entrypoint` option can override the configured entrypoint.

Shell form, such as `CMD python -m myapp`, runs through a shell. It can support shell features like expansion and pipelines, but it does not behave like exec form when combined with an entrypoint or runtime arguments. For predictable argument handling and signal delivery, prefer exec form; use a small wrapper when initialization is required, and have it ultimately `exec` the application process.

Key points

• Use exec-form `ENTRYPOINT` for the usual executable and `CMD` for its default arguments.
• Arguments after the image name replace the image's `CMD` values.
• Without `ENTRYPOINT`, `CMD` defines the whole default command.
• Prefer exec form for services unless shell behavior is deliberately needed.
• Use `exec` in shell wrappers so the application becomes the directly running process.

Interview questions

How would you choose ENTRYPOINT and CMD for a Python service image?

Use exec-form `ENTRYPOINT` to name the application executable and exec-form `CMD` to provide its default arguments. For example, `ENTRYPOINT ["python", "-m", "myapp"]` starts the application, and a runtime argument can replace the default arguments when they are supplied through `CMD`. This keeps the executable stable while making defaults configurable. If operators need to replace the entire command, omit ENTRYPOINT or provide a documented override path.

What does `docker run image ARG...` do when the image defines both instructions?

With exec-form ENTRYPOINT and CMD, Docker combines the entrypoint array with the CMD array to form the process arguments. Extra arguments after the image name replace CMD, and Docker appends those arguments to ENTRYPOINT. For example, with `ENTRYPOINT ["python", "-m", "myapp"]` and `CMD ["--port", "8000"]`, running `docker run image --port 9000` starts Python with `--port 9000`. The entrypoint can instead be overridden with Docker's `--entrypoint` option.

How do exec form and shell form differ in a Dockerfile?

Exec form uses a JSON array to pass an executable and separate arguments directly, without implicitly starting a shell. Shell form runs a command through a shell, so shell syntax and expansions may be available. The forms differ in how runtime arguments interact with the command and in which process receives signals. For a long-running service, exec form is usually simpler; use a shell wrapper only when its behavior is needed.

Why does ENTRYPOINT design matter for shutdown and signal handling?

A container's main process commonly runs as PID 1, so signal handling and child-process reaping deserve attention. If a shell sits between Docker and the application, the application may not receive signals as expected unless the shell forwards them. A wrapper can initialize the environment and then use `exec` to replace itself with the application. That makes the application the directly executed process rather than leaving the shell as an extra parent.

When would you use CMD without ENTRYPOINT?

Use CMD alone when the image's default executable should be easy to replace, such as a general-purpose base image or an image used for different commands. Use ENTRYPOINT when the image represents a specific tool or service and should keep the same executable while accepting different arguments. Both can be combined when a stable executable has sensible default arguments. The choice should make the intended runtime override behavior clear to image users.