liveBook · Manning

Exec form

As explained in Kubernetes in Action, Second Edition

The exec form is Dockerfile syntax that invokes an ENTRYPOINT or CMD executable directly without starting a shell.

The exec form is Dockerfile syntax that invokes an ENTRYPOINT or CMD executable directly, without starting a shell. For example: ENTRYPOINT ["/myexecutable", "1st-arg", "2nd-arg"]. The executable becomes the container’s root process. section 6.3.2

This process relationship matters when a container receives SIGTERM. With exec form, the application receives the signal directly. With shell form, the shell becomes the root process and may not pass SIGTERM to its child application, so replacing shell form is usually preferable to adding a signal-sending pre-stop hook. section 6.3.2

Direct versus shell invocation

Exec form: ENTRYPOINT ["/myexecutable", "1st-arg", "2nd-arg"]. Shell form: ENTRYPOINT /myexecutable 1st-arg 2nd-arg. If a shell script starts the application instead, the script must forward signals or use the exec shell command. section 6.3.2

How Kubernetes in Action, Second Edition covers it

How deep it goes
Explains process ownership and signal behavior, then contrasts exec form with shell form and shell-script forwarding.
Examples
Uses ENTRYPOINT array and string examples, plus a shell-script signal-forwarding case.
What it assumes
Assumes familiarity with Dockerfile ENTRYPOINT or CMD directives and introduces their exec and shell forms directly.
What you can do after
Configure ENTRYPOINT or CMD so the application becomes the container root process and receives termination signals.
How it connects
Connects ENTRYPOINT and CMD with shell form, SIGTERM, pre-stop hooks, and container lifecycle.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.