cmd和dockefile中的入口点之间的区别

Question

我是Docker的新手，对ockfile有一个简单的问题。 我们可以在停靠文件中写入入口点和CMD。 似乎在创建容器期间执行了入口点。 并且在启动容器期间执行CMD。 这是真的？

Answer 1

不完全是：

ENTRYPOINT配置一个将作为可执行文件运行的容器。
因此它总是被执行（或默认的/bin/sh -c是）。

ENTRYPOINT ["executable", "param1", "param2"] (exec form, preferred)
ENTRYPOINT command param1 param2 (shell form)

ENTRYPOINT docker run <image>命令行参数将附加在exec形式ENTRYPOINT所有元素之后，并将覆盖使用CMD指定的所有元素。

shell形式可防止使用任何CMD或运行命令行参数，但具有以下缺点： ENTRYPOINT将作为/bin/sh -c的子命令启动，该子命令不传递信号。
这意味着可执行文件将不是容器的PID 1，并且不会接收Unix信号，因此您的可执行文件将不会从docker stop <container>接收到SIGTERM。

您可以将CMD视为ENTRYPOINT参数。
如果没有入口点（默认命令为“ /bin/sh -c ”），则CMD可以包含可执行文件。
如果ENTRYPOINT已经运行了可执行文件，则CMD参数是该命令的参数（如果使用docker run而没有其他参数）。

---

使用docker start ，如问题1437中所述 ，将执行ENTRYPOINT ，但仅使用CMD参数（因此使用CMD ，但不能在命令行上使用您自己的参数覆盖它）。
如果要使用CMD，则需要docker run ，而不是docker start 。

实际上，最近有一个正在进行的PR （ PR 19746 ），它允许--cmd start命令使用可选的--cmd （ -c ）标志来指定要使用的cmd，而不是cmd / entrypoint中的默认cmd。

---

Dockerfile官方文档现在具有“ 了解CMD和ENTRYPOINT如何交互 ”部分：

• Dockerfile应至少指定CMD或ENTRYPOINT命令之一。
• 使用容器作为可执行文件时，应定义ENTRYPOINT 。
• 应将CMD用作为ENTRYPOINT命令定义默认参数或在容器中执行自定义命令的方式。
• 使用替代参数运行容器时， CMD将被覆盖。

这意味着，如果您的Dockerfile包含：

• 没有CMD ：

  • 如果没有ENTRYPOINT ：错误，则不允许
  • ENTRYPOINT exec_entry p1_entry表示/bin/sh -c exec_entry p1_entry
  • ENTRYPOINT ["exec_entry", "p1_entry"]表示exec_entry p1_entry

• CMD ["exec_cmd", "p1_cmd"] （一个命令，一个参数）

  • 如果没有ENTRYPOINT ： exec_cmd p1_cmd ，
  • ENTRYPOINT exec_entry p1_entry表示/bin/sh -c exec_entry p1_entry exec_cmd p1_cmd
  • ENTRYPOINT ["exec_entry", "p1_entry"]表示exec_entry p1_entry exec_cmd p1_cmd

• CMD ["p1_cmd", "p2_cmd"]

  • 如果没有ENTRYPOINT ： p1_cmd p2_cmd
  • ENTRYPOINT exec_entry p1_entry表示/bin/sh -c exec_entry p1_entry p1_cmd p2_cmd （好）
  • ENTRYPOINT [“exec_entry”, “p1_entry”]表示exec_entry p1_entry p1_cmd p2_cmd

• CMD exec_cmd p1_cmd ：

  • 如果没有ENTRYPOINT ： /bin/sh -c exec_cmd p1_cmd
  • ENTRYPOINT exec_entry p1_entry表示/bin/sh -c exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd
  • ENTRYPOINT [“exec_entry”, “p1_entry”]表示exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd