在Dockerfile中,有两个命令与我类似:CMD和ENTRYPOINT。但我想它们之间有一个(微妙的)区别——否则,对同一件事使用两个命令是没有意义的。
CMD的文档状态-
CMD的主要目的是为正在执行的容器提供默认值。
对于入口点:
ENTRYPOINT帮助您配置可以作为可执行文件运行的容器。
那么,这两个命令之间有什么区别?
在Dockerfile中,有两个命令与我类似:CMD和ENTRYPOINT。但我想它们之间有一个(微妙的)区别——否则,对同一件事使用两个命令是没有意义的。
CMD的文档状态-
CMD的主要目的是为正在执行的容器提供默认值。
对于入口点:
ENTRYPOINT帮助您配置可以作为可执行文件运行的容器。
那么,这两个命令之间有什么区别?
当前回答
通过从头开始重建OS映像(只需从头开始编写,并在dockerfile中使用COPY复制最小的文件系统),我了解到,
如果没有在dockerfile中指定ENTRYPOINT和CMD,docker将使用
/bin/sh -c
作为默认ENTRYPOINT,如果在docker文件中定义CMD或在运行容器时传递命令行参数(这将覆盖已定义的CMD),则将采用CMD。
假设您传递一个参数(或在dockerfile中定义CMD)ls,那么它将被馈送到ENTRYPOINT。即,
/bin/sh -c ls
/bin/sh-c将运行传递给它的任何参数。您将获得“ls”命令的输出,然后容器将退出。
ubuntu映像没有显式定义ENTRYPOINT,因此docker将使用/bin/sh-c,但包含CMD定义,即bash运行容器的以下命令,
docker container run -it ubuntu
Docker实际上使用ENTRYPOINT作为/bin/sh-c,然后使用bash为其提供数据最终运行的是
/bin/sh -c bash
它启动交互式bash终端(仅当如上所述指定了-i标志并可选地指定了-t以获得类似本地终端的体验时)
当您通过命令行提供参数时,bash将被替换为您传递的任何内容,输出将根据该内容,即
/bin/sh -c passed_argument
您可以定义自定义ENTRYPOINT,它将覆盖默认ENTRYPOINT,但随后需要相应地使用CMD。
对于dockerfile中的RUN命令,它不考虑定义的ENTRYPOINT和CMD,而是运行指定的命令,因为它们被提供给中间容器中的交互式bash终端
其他回答
大多数人在这里都解释得很好,所以我不会重复所有的答案。但为了得到一个好的感觉,我建议自己通过查看容器中的流程来测试它。
创建一个小型Dockerfile,格式如下:
FROM ubuntu:latest
CMD /bin/bash
构建它,用docker run-it-theimage运行它,并在容器中运行ps-eo-ppid、pid和args。使用以下选项时,将此输出与从ps接收的输出进行比较:
docker run-it theimage bash重建图像,但使用ENTRYPOINT/bin/bash并以两种方式运行使用CMD[“/bin/bash”]...
这样,您将很容易看到所有可能的方法之间的差异。
Dockerfile文件中提到的CMD命令可以通过docker run命令覆盖,而ENTRYPOINT不能覆盖。
我想以轻松的方式区分CMD、RUN和ENTRYPOINT之间的差异。
让我们以节点的npm init为例。
命令:
假设下面是我们在dockerfile中添加的初始命令
CMD [ "npm", "init" ]
现在,如果我运行docker,运行-t node npm install
它将覆盖dockerfile中的npm init命令。
CMD [ "npm", "init" ] This will become CMD [ "npm", "install" ]
它将执行npm install命令,而不是npm init,因为它会使用npm install。
现在,我们来谈谈
入口点:
假设在docker文件中添加了相同的命令,但使用ENTRYPOINT
ENTRYPOINT [ "npm", "init" ]
现在,如果我运行docker,运行-t节点安装
它将在dockerfile中附加npm init命令和npm install。
ENTRYPOINT [ "npm", "init" ] This will become ENTRYPOINT [ "npm", "init", "install" ]
它将同时执行npm init和npm install命令。
总结如下:
RUN:这将在生成图像时执行。用于安装任何依赖项,如node_modules。例如RUN npm安装
CMD:要覆盖完整命令时使用
ENTRYPOINT:要附加一些附加命令时使用。
CMD:
CMD[“executable”,“param1”,“param2”]:[“executible”,”param1“,”param2“]是第一个进程。CMD命令param1 param2:/bin/sh-c CMD命令param1 param2是第一个进程。CMD命令param1 param2从第一个进程分叉。CMD[“param1”,“param2”]:此表单用于为ENTRYPOINT提供默认参数。
ENTRYPOINT(以下列表不考虑CMD和ENTRYPOINT一起使用的情况):
ENTRYPOINT[“executable”,“param1”,“param2”]:[“executible”,”param1“,”param2“]是第一个进程。ENTRYPOINT命令param1 param2:/bin/sh-c命令param1 param2是第一个进程。命令param1 param2从第一个进程分叉。
正如creack所说,CMD是第一个开发的。然后,ENTRYPOINT被开发用于更多的定制。由于它们不是一起设计的,CMD和ENTRYPOINT之间存在一些功能重叠,这常常会让人感到困惑。
通过从头开始重建OS映像(只需从头开始编写,并在dockerfile中使用COPY复制最小的文件系统),我了解到,
如果没有在dockerfile中指定ENTRYPOINT和CMD,docker将使用
/bin/sh -c
作为默认ENTRYPOINT,如果在docker文件中定义CMD或在运行容器时传递命令行参数(这将覆盖已定义的CMD),则将采用CMD。
假设您传递一个参数(或在dockerfile中定义CMD)ls,那么它将被馈送到ENTRYPOINT。即,
/bin/sh -c ls
/bin/sh-c将运行传递给它的任何参数。您将获得“ls”命令的输出,然后容器将退出。
ubuntu映像没有显式定义ENTRYPOINT,因此docker将使用/bin/sh-c,但包含CMD定义,即bash运行容器的以下命令,
docker container run -it ubuntu
Docker实际上使用ENTRYPOINT作为/bin/sh-c,然后使用bash为其提供数据最终运行的是
/bin/sh -c bash
它启动交互式bash终端(仅当如上所述指定了-i标志并可选地指定了-t以获得类似本地终端的体验时)
当您通过命令行提供参数时,bash将被替换为您传递的任何内容,输出将根据该内容,即
/bin/sh -c passed_argument
您可以定义自定义ENTRYPOINT,它将覆盖默认ENTRYPOINT,但随后需要相应地使用CMD。
对于dockerfile中的RUN命令,它不考虑定义的ENTRYPOINT和CMD,而是运行指定的命令,因为它们被提供给中间容器中的交互式bash终端