不完全是：

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

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

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

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

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

随着docker start，如中提到的问题1437时，ENTRYPOINT被执行，但只有从参数CMD（所以CMD被使用，但你不能用你自己的命令行参数覆盖它）。
如果你想使用CMD，你需要docker run，没有docker start。

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

该官方Dockerfile文档现在有一个部分“
了解如何CMD和入口点互动 ”：

• 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