When creating Dockerfiles the commands CMD and ENTRYPOINT enable you to specify a startup command for an image. Any image that does not have a startup command will fail to run. Although Docker ENTRYPOINT & CMD enable you to specify a startup command there are some differences between the two. Although they can be used jointly these differences make either command to be preferable over the other in some situations.
An ENTRYPOINT setting specifies both the command and parameters to be run when a container is initialized. All arguments passed when running a container will be included in ENTRYPOINT command and they will override any options specified by CMD. As an example if we run a container using the command docker run [container] bash then bash argument will be after ENTRYPOINT specifications.
When writing your Dockerfiles you are required to capitalize entrypoint instructions. There are different ways in which entrypoint instructions can be specified. One approach is to use exec syntax. The exec syntax requires commands and arguments are specified in JSON format. Therefore double instead of single quotes are required. An example of exec syntax is shown below
ENTRYPOINT[“arg1”, “arg2”, “arg3”, “arg4”]The syntax specified above does not instruct Docker to use shell processing. When you need shell processing you have to begin your syntax by specifying a shell command as shown below
ENTRYPOINT [“sh”, “-c”, “echo $HOME” ]
Another approach to specify entrypoint instructions is using an entrypoint script to run commands. The script includes entrypoint reference, applications, configurations and environment variables required. After creating your script you can run it as shown below
COPY /path to script.sh ENTRYPOINT [“path to script.sh”] CMD [“postgres”]
The third approach is to use Docker Compose entrypoint. This is done by specifying a path using lower case. An example is shown below
entrypoint : path to script.sh
An alternative is to specify a list in docker-compose.yml. An example is shown below
entrypoint :
-postgres
-d
-memory_limit = -1
The CMD command is mainly used to specify defaults which are executed after entrypoint. When creating a Dockerfile you specify CMD defaults that include an executable. An example of this syntax is shown below
CMD [“executable”, “params…”]
Because of simplicity of overriding CMD it is an excellent choice when you would like to provide the image user the flexibility of selecting executable when running the container. On the other hand ENTRYPOINT is preferable when you would not like or you do not expect the end user to need flexibility. Although CMD can achieve similar results as ENTRYPOINT the use of ENTRYPOINT emphasizes the container is to be run as is.
Either ENTRYPOINT or CMD support shell or exec form. The shell form of either command will run successfully but there are subtleties’ that need to be considered. For example it may not be possible to send POSIX signals to child processes. This occurs because ENTRYPOINT shell does not allow CMD or run arguments to be used. Due to this restriction entrypoint is started as a subcommand of /bin/sh –c which can’t pass signals. Other problems may arise when building a minimal image that does not include a shell. When Docker checks and does not find a shell the container will not run. Due to these unforeseen issues that may arise it is preferable to use exec form of CMD/ENTRYPOINT
Previous best practices have focused on use of either CMD or ENTRYPOINT. However there are situations where it is preferable to use CMD and ENTRYPOINT. When the two commands are used together you are able to specify default executable together with its default arguments which the user has the flexibility of changing. When CMD and ENTRYPOINT are used jointly it is important the exec form is used. Inconsistent use of exec form may lead to results you were not expecting.
In this tutorial, the CMD and ENTRYPOINT commands were introduced. The use of each command was discussed and syntax examples were given. Situations, where either command would be preferable, were discussed. Situations, where the use of both commands was preferable, were also discussed.
