Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Detailed explanation of CMD and ENTRYPOINT commands in Dockerfile

2025-01-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/02 Report--

Preface

Both the CMD and ENTRYPOINT directives are used to specify the commands to run when the container starts.

Functionally, the two commands are almost repetitive. The vast majority of use cases can be achieved by using one of them alone. But since doker provides them at the same time, in order not to be confused in use, this paper attempts to make their usage clear. There is no more to say below, let's take a look at the detailed introduction.

Exec mode and shell mode

Both CMD and ENTRYPOINT instructions support the writing of exec mode and shell mode, so to understand the use of CMD and ENTRYPOINT instructions, you have to distinguish between exec mode and shell mode. These two modes are mainly used to specify that the different processes in the container are process 1. Friends who know linux should be aware of the importance of process 1 in the system. The author also introduced the importance of No. 1 process to the signal processing in the container in the article "capturing the signal in the docker container". Interested friends can come here to understand. Let's learn the characteristics of exec mode and shell mode through CMD instructions.

Exec mode

When using exec mode, the task process in the container is process No. 1 in the container. See the following example:

FROM ubuntuCMD ["top"]

Save the above code to Dockerfile in the test1 directory, then go to the test1 directory to build the image and start a container:

$docker build-t test1. $docker run-idt-- name testcon test1

Then look at the process ID in the container:

$docker exec testcon ps aux

From the figure, we can see that the process running the top command has an ID of 1.

Exec mode is the recommended mode, because when the process running the task is process 1 in the container, we can gracefully end the container with the docker stop command (see "capturing signals in the docker container" for details).

The characteristic of exec mode is that relevant commands are not executed through shell, so environment variables such as $HOME are not available:

FROM ubuntuCMD ["echo", "$HOME"]

Save the above code to Dockerfile in the test1 directory, then go to the test1 directory to build the image and start a container:

$docker build-no-cache-t test1. $docker run-rm test1

Environment variables can be obtained by executing shell in exec mode:

FROM ubuntuCMD ["sh", "- c", "echo $HOME"]

Save the above code to Dockerfile in the test1 directory, then go to the test1 directory to build the image and start a container:

$docker build-no-cache-t test1. $docker run-rm test1

This time the value of the $HOME environment variable is taken correctly.

Shell mode

When using shell mode, docker executes task commands in the form of / bin/sh-c "task command". In other words, process 1 in the container is not a task process but a bash process. Take a look at the following example:

FROM ubuntuCMD top

Save the above code to Dockerfile in the test2 directory, then go to the test2 directory to build the image and start a container:

$docker build-t test2. $docker run-itd-- name testcon2 test2

Then look at the process ID in the container:

$docker exec testcon2 ps aux

The command executed by process 1 is actually / bin/sh-c top. The process ID of the top command we specified is 7. This is determined internally by docker so that the commands or scripts we execute can fetch environment variables.

CMD instruction

The purpose of the CMD directive is to provide default execution commands for the container.

The CMD directive can be used in three ways, one of which is to provide default parameters for ENTRYPOINT:

CMD ["param1", "param2"]

The other two modes of use are exec mode and shell mode:

CMD ["executable", "param1", "param2"] / / this is written in exec mode, note that double quotation marks are required. CMD command param1 param2 / / this is the way shell mode is written.

Note that command-line arguments can override the settings of the CMD instruction, but can only be overridden, but cannot be passed to commands in CMD through the command line.

General images provide the default command when the container starts, but in some scenarios users do not want to execute the default command. Users can override the default commands provided by the CMD directive as command-line arguments. For example, the image created by the following command:

FROM ubuntuCMD ["top"]

When starting the container, we override the default top command by specifying the parameter ps aux on the command line:

As you can see from the figure above, the ps aux command specified on the command line overrides the CMD ["top"] in Dockerfile. In fact, the command on the command line also overrides the CMD instruction in shell mode.

ENTRYPOINT instruction

The purpose of the ENTRYPOINT directive is also to specify the tasks to be performed by default for the container.

The ENTRYPOINT directive can be used in two ways, namely, exec mode and shell mode, which we introduced earlier:

ENTRYPOINT ["executable", "param1", "param2"] / / this is written in exec mode, note that double quotation marks are required. ENTRYPOINT command param1 param2 / / this is the way shell mode is written.

The basic usage of exec mode and shell pattern is the same as the CMD directive, so let's introduce some more special uses.

When you specify that the ENTRYPOINT directive is in exec mode, the parameters specified on the command line are added as arguments to the argument list of the ENTRYPOINT specified command. Build the mirror test1 with the following code:

FROM ubuntuENTRYPOINT ["top", "- b"]

Run the following command:

$docker run-rm test1-c

The parameters we added on the command line are appended to the argument list of the top command.

Default optional parameters are specified by the CMD directive:

FROM ubuntuENTRYPOINT ["top", "- b"] CMD ["- c"]

Use this code to build an image test2 and start the container without command line arguments:

$docker run-rm test2

The command that runs in the container is: top-b-c.

If we specify command line arguments:

$docker run-- rm test2-n 1

-n 1 overrides the parameters specified through CMD ["- c"]. The command executed by the container is: top-b-n 1

Notice that the output of the above figure shows that the-c parameter is overridden.

When you specify that the ENTRYPOINT directive is in shell mode, the command line arguments are completely ignored:

FROM ubuntuENTRYPOINT echo $HOME

Compile the above code into a mirror test2, executing commands without command-line arguments and using command-line arguments ls:

We see that the ls command is not executed, which means that the command-line arguments are ignored by the shell mode of the ENTRYPOINT instruction.

Override the default ENTRYPOINT directive:

The ENTRYPOINT instruction can also be overridden by the command line, but instead of the default command line argument, the entrypoint parameter needs to be explicitly specified. For example, we overwrite the echo $HOME command in the image above by:

$docker run-rm-entrypoint hostname test2

Here we override the default echo $HOME command with the hostname command.

There must be at least one Dockerfile.

If neither CMD nor ENTRYPOINT is specified in the image, an error will be reported when starting the container. This is not a problem, because most of the images you can see now have CMD or ENTRYPOINT instructions added by default.

If you specify any one, the effect is about the same.

As a result, CMD and ENTRYPOINT are the same, and we can achieve the same goal through them. Let's set up the top-b command with CMD and ENTRYPOINT, respectively, and then observe the metadata information when the container is running:

Or:

Although the implementation is different, the final command that the container runs is the same.

Using CMD and ENTRYPOINT at the same time

For the design of CMD and ENTRYPOINT, in most cases they should be used separately. One exception, of course, is that CMD provides default optional parameters for ENTRYPOINT.

We can probably sum up the following rules:

If ENTRYPOINT uses shell mode, the CMD instruction is ignored.

If ENTRYPOINT uses exec mode, the content specified by CMD is appended to the parameters of the command specified by ENTRYPOINT.

If ENTRYPOINT uses exec mode, CMD should also use exec mode.

The real situation is much more complicated than these three laws, but docker gives an official explanation, as shown in the following figure:

When we can't understand the behavior of running commands in the container, maybe we can solve the confusion through this table!

Summary

CMD and ENTRYPOINT are very important instructions for Dockerfile. They are not executed during the process of building the image, but when the container is started, so they are mainly used to specify the commands that the container executes by default. However, providing two instructions with similar functions will inevitably bring confusion to the user in understanding and confusion in use. I hope this article can help you understand the difference and relationship between the two, and make better use of the two.

Reference:

Docker official documentation

ENTRYPOINT vs CMD: Back to Basics

Dockerfile: ENTRYPOINT vs CMD

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report