ENTRYPOINT and CMD
-------------------

CMD vs ENTRYPOINT
~~~~~~~~~~~~~~~~~

**CMD**::

  CMD ["/bin/ping", "-c", "3", "localhost"]

- Easy to override: use for general purpose images

**ENTRYPOINT**::

  CMD ["/bin/ping", "-c", "3", "localhost"]

- Not made to be overridden: use for specific applications

**CMD and ENTRYPOINT**::

  ENTRYPOINT ["/bin/ping", "-c", "3"]
  CMD ["localhost"]

- CMD is appended to ENTRYPOINT
- Specifies the executable with ENTRYPOINT and the arguments with CMD
- The CMD arguments can be overridden by the user of your container
- Always use the **exec form** when combining both


Shell vs. Exec
~~~~~~~~~~~~~~

With the **shell form**, docker will invoke a shell and pass the specified commands to it::

  CMD ping localhost

This will be executed as ``/bin/sh -c 'ping localhost'`` by docker.

Consequences of the shell form:
- the process with PID 1 is the shell and not your application
- POSIX signals will be sent to the shell and not forwarded to your application
- the container needs to provide a shell at ``/bin/sh``
- variable expansion will happen as you would expect

With the **exec form**, docker executes your commands directly in the container, without starting a shell::

  CMD ["/bin/ping", "localhost"]

Consequences of the exec form:
- your process is the PID 1, receiving all signals
- no shell needed in the container
- your command is interpreted as is, and there is **no variable expansion** (since there is no shell)

Forward signals
~~~~~~~~~~~~~~~

If using the shell form or a startup script, we can handle signals correctly by using the ``exec gosu`` combo command while starting the application.

This is the official ``Dockerfile`` example using this technique::

  #!/usr/bin/env bash
  set -e
  
  if [ "$1" = 'custom-app' ]; then
      # do something
      exec gosu custom-app "$@"
  fi
  
  exec "$@"