The ENTRYPOINT instruction will help in crafting an image for running an application (entry point) during the complete life cycle of the container, which would have been spun out of the image. When the entry point application is terminated, the container would also be terminated along with the application and vice versa. Thus, the ENTRYPOINT instruction would make the container function like an executable. Functionally, ENTRYPOINT is akin to the CMD instruction, but the major difference between the two is that the entry point application is launched using the ENTRYPOINT instruction, which cannot be overridden using the docker run subcommand arguments. However, these docker run subcommand arguments will be passed as additional arguments to the entry point application. Having said this, Docker provides a mechanism for overriding the entry point application through the --entrypoint option in the docker run subcommand. The --entrypoint option can accept only words as its argument and hence, it has limited functionality.

Syntactically, the ENTRYPOINT instruction is very similar to the RUN and CMD instructions, and it has two types of syntax, as shown here:

• The first type of syntax is the shell type, as shown here:

      ENTRYPOINT <command> 

Here, <command> is the shell command, which is executed during the launch of the container. If this type of syntax is used, then the command is always executed using /bin/sh -c.

• The second type of syntax is exec or the JSON array, as shown here:

      ENTRYPOINT ["<exec>", "<arg-1>", ..., "<arg-n>"] 

Here, the code terms mean the following:

Syntactically, you can have more than one ENTRYPOINT instruction in a Dockerfile. However, the build system will ignore all the ENTRYPOINT instructions except the last one. In other words, in the case of multiple ENTRYPOINT instructions, only the last ENTRYPOINT instruction will be effective.

In order to gain a better understanding of the ENTRYPOINT instruction, let's craft an image using Dockerfile with the ENTRYPOINT instruction and then launch a container using the crafted image. The following is Dockerfile with an ENTRYPOINT instruction to echo a text:

######################################################## 
# Dockerfile to demonstrate the behavior of ENTRYPOINT 
######################################################## 
# Build from base image busybox:latest 
FROM busybox:latest 
# Author: Dr. Peter 
MAINTAINER Dr. Peter <[email protected]> 
# Set entrypoint command 
ENTRYPOINT ["echo", "Dockerfile ENTRYPOINT demo"] 

Now, let's build a Docker image using the docker build as the subcommand and entrypoint-demo as the image name. The docker build system would read the instruction from Dockerfile stored in the current directory (.) and craft the image, as shown here:

$ sudo docker build -t entrypoint-demo .

Having built the image, we can launch the container using the docker run subcommand:

$ sudo docker run entrypoint-demo
Dockerfile ENTRYPOINT demo  

Here, the container will run like an executable by echoing the Dockerfile ENTRYPOINT demo string and then it will exit immediately. If we pass any additional arguments to the docker run subcommand, then the additional argument would be passed to the ENTRYPOINT command. The following is the demonstration of launching the same image with the additional arguments given to the docker run subcommand:

$ sudo docker run entrypoint-demo with additional arguments
Dockerfile ENTRYPOINT demo with additional arguments  

Now, let's see an example where we override the build time entry point application with the --entrypoint option and then launch a shell (/bin/sh) in the docker run subcommand, as shown here:

$ sudo docker run -it --entrypoint="/bin/sh" entrypoint-demo
/ #