At first glance, the commands in Dockerfile appear to be repeating themselves (or at the very least have significant overlap). ENTRYPOINT and CMD are two Dockerfile directives that are frequently misunderstood. While they both allow you to specify the image’s starting command, there are a few differences between them.
You’ll want to utilise one or the other in most of the cases, but they may also be used simultaneously. CMD and Entrypoint are two of the three types of instructions (commands) that you employ to construct and run Dockerfiles:
CMD: When a container is operating, CMD sets default settings that can be changed using the Docker Command Line Interface (CLI).
ENTRYPOINT: When Docker Containers are run using CLI arguments, the default parameters cannot be changed.
For containers to run, any Docker image must have an ENTRYPOINT or CMD declaration. Though the ENTRYPOINT and CMD instructions appear to be identical at first sight, they create container images in quite different ways.
Shell form vs executable form
We must first comprehend how a Docker Daemon interprets instructions once they have been passed. All Docker commands (instructions) can be given in shell or exec formats. To better comprehend these two instructions, let’s create a sample Dockerfile.
1. Shell command form
A shell instruction, as the name implies, starts operations that execute inside the shells. To run this command, type /bin/sh -c command>. Every execution of a shell command usually necessitates the validation of environment variables before providing the results. Shell command syntax is specified in the following format:
The command form calls a shell that performs validation before providing results, resulting in performance bottlenecks. As a result, shell forms are not usually the best choice unless there is a specific requirement for command/environment validation.
2. Executable command form
Here, an instruction gets expressed in executable form and runs the executable binary directly without passing through shell verification and execution. Syntaxes for executable commands are given in the following format:
<instruction> [“executable”, “parameter 1”, “parameter 2”, …]
In a containerized architecture, executable commands are necessary instructions that are provided to the operating environment in order to achieve the intended result. It’s critical to use the correct command form when providing instructions so that you can:
- Provide the desired outcome
- Make sure you’re not putting the environment through excessive processing, which will reduce operating efficiency
A Docker image’s default execution is defined by Docker CMD. These images may be used as the foundation for a container without the need for command-line parameters. Therefore, the container executes the CMD commands designated for them to process.
While launching containers, the CMD instruction is only used if the run command has no arguments. As a result, adding an argument to the command overrides the CMD. Docker CMD commands are supplied through a Dockerfile, which contains the commands for the following:
- Building a Docker image instructions
- Binaries for executing a container atop an image by default
The ability to override is an important feature of CMD command. This enables users to override CMD instructions in a Dockerfile by executing commands using the CLI. A Docker CMD command can be written in Shell or Exec formats.
- Exec form
CMD [“executable”, “parameter1”, “parameter2”]
- Shell form:
CMD command parameter1 parameter2
Building an Image and Creating a Dockerfile using CMD
- To begin, create a new MyDockerImage folder in which you want to save your image:
sudo mkdir MyDockerImage
- Create a new Dockerfile in that directory.
sudo touch Dockerfile
- Use your preferred text editor to open the Dockerfile
- Then, in the file, add the following content:
RUN apt-get update
CMD [“echo”, “Hello World”]
When containers start up without a command, use the CMD instruction to echo the message ‘Hello World’, as shown in the aforementioned code. Right after this, save the file and close it.
- Now it is the time to create a Docker image using the freshly created Dockerfile. You don’t need to provide the location of the Dockerfile because we’re still in the MyDockerImage directory; simply build the image by executing:
sudo docker build
- The name of the container will be shown in the output. Run the following command to test if it’s available among the locally saved images:
sudo docker images
Using CMD to run a Docker Container
Build a container based on the picture we generated in the previous stage to show CMD in action. Use the following command to start the container:
sudo docker run [image_name]
The containers will perform the default CMD instruction and show the “Hello World” message because there is no command-line parameter. When you initialize a container with an argument, however, it will override the CMD instruction. Add the hostname option to the docker run command, such as:
sudo docker run [image_name] hostname
Rather than using the CMD’s echo command, Docker will use the container and the hostname command.
When to use CMD
The ideal approach to utilise a CMD instruction is to define default programs that should execute if the user does not provide any parameters on the command line. This command guarantees that the containers are operating by launching applications as soon as the container image is loaded.
The CMD parameter loads the base image as soon as the container starts by doing so. Additionally, to overrule instructions given in the Dockerfile, a docker run command can be issued using a CLI in particular use-cases.
Every time a container starts, the image’s entrypoint specifies the process that will execute. The default entrypoint for Docker is /bin/sh -c. It implies that you’ll be at a shell prompt when starting a container. By default, launching a separate process for each container is preferable. Your headless services should start working immediately.
In a Dockerfile, the ENTRYPOINT directive tells Docker to execute a specified command when the container begins. Instead of the normal shell session, it will become the forefront process.
Both shell and exec versions of the Docker ENTRYPOINT directive are supported:
- Exec form
ENTRYPOINT [“executable”, “parameter1”, “parameter2”]
- Shell form
ENTRYPOINT command parameter1 parameter2
The date command will be run by a container built using this Dockerfile. The container will quit soon because it is not a long-lived foreground process.
Scripts or executable binaries must be used as entrypoints. If you supply an incorrect entrypoint, your container will not start. Make sure the executable bit is set if you’re using a custom script. chmod +x my-script.sh can be used to add and execute permissions.
Building an Image and Creating a Dockerfile with ENTRYPOINT
- To modify the instructions, use the Dockerfile produced in the CMD section and edit the file. Using a text editor, open the existing file:
sudo nano Dockerfile
- Replace the CMD command with ENTRYPOINT to edit the content. The file should be saved and closed right after this.
RUN apt-get update
ENTRYPOINT [“echo”, “Hello World”]
Using ENTRYPOINT to run a Docker Container
- Use the following command to create a new image:
sudo docker build .
- The result should reflect that you’ve successfully created a new picture with the specified name. Let’s run it in a container now, without any command-line options. The result will be identical to that of CMD. This is because we haven’t given the run command in any of the arguments.
sudo docker run [container_name]
- You must provide a parameter when launching a container to observe how ENTRYPOINT works. Use the same command as before, but add something to the end of the container name:
sudo docker run [container_name] KnowledgeBase
As we can observe, Docker did not override the original command to echo Hello World. The new argument was simply added to the current command. Although ENTRYPOINT and CMD can be used in both forms, it is typically recommended that you use the exec form. Because shell shape can occasionally cause subtle difficulties in the process, this is the more dependable approach.
When should you use ENTRYPOINT?
ENTRYPOINT instructions can be used in both single-purpose and multi-mode images and a certain command must be performed every time the container begins.
One of the most typical use cases is building wrapper containers-images that encloses older applications for containerization, that uses an ENTRYPOINT command to ensure the application always runs.
CMD vs ENTRYPOINT: Differences
In a nutshell, CMD specifies the container’s default commands and/or arguments. If you require a default command that users can simply override, CMD is the ideal command to employ. If a Dockerfile contains several CMDs, just the instructions from the latest one are used. When you wish to establish a container with a specific executable, however, ENTRYPOINT is preferable. When launching a container, you can’t override an ENTRYPOINT unless you use the entrypoint parameter.
If you require containers with a defined executable and default parameters that can be changed simply, use ENTRYPOINT with CMD. For example it will set environment-specific variables when containerizing an application. The functions of the CMD and ENTRYPOINT instructions are fundamentally distinct, making them suited for diverse applications, settings, and circumstances. They both provide programs that run when the container starts up, but they differ in the following ways:
- When creating an executable Docker image with commands that must always be performed, use ENTRYPOINT instructions.
- CMD instructions are best for an extra set of parameters that function as default directives until a Docker container starts with an explicit command line use.
The ENTRYPOINT and CMD commands in Docker are frequently misunderstood. Their names conceal their true intentions. Set the ENTRYPOINT for commands that will be executed when new containers start. Using CMD, you may set default parameters. The container’s final command string is created by combining ENTRYPOINT and CMD.
You will need to include an ENTRYPOINT or CMD in your Dockerfile if you want your image to do something useful when it runs. You should not consider them as mutually exclusive. Utilizing both at the same time will greatly improve user experience.