我遇到了这个问题，一开始我发现老实说，这真的很令人困惑，我认为这种困惑来自于使用“CMD”一词，因为事实上，那里的东西充当了论据。所以挖了一点后，我明白了它是如何工作的。基本上：

ENTRYPOINT-->此处指定的是容器启动时要执行的命令。如果省略此定义，docker将使用/bin/sh-cbash来运行容器。

CMD-->这些是附加到ENTRYPOINT的参数，除非用户指定了一些自定义参数，即：docker run ubuntu＜custom_CMD＞在这种情况下，docker将运行ENTRYPOINT＜custom_CMD＞，而不是附加在CMD部分的图像上指定的内容。如果未指定ENTRYPOINT，则此处的内容将传递给/bin/sh-c，实际上作为启动容器时要执行的命令。

作为一切，最好用例子来解释发生了什么。因此，假设我使用以下规范Dockerfile创建了一个简单的docker映像：

From ubuntu
ENTRYPOINT ["sleep"]

然后我通过运行以下命令来构建它：

docker build . -t testimg

这将创建一个容器，每次运行时它都会休眠。所以，如果我按如下方式运行：

docker run testimg

我会得到以下信息：

sleep: missing operand
Try 'sleep --help' for more information.

这是因为入口点是需要参数的“sleep”命令。为了解决这个问题，我只需要提供睡眠量：

docker run testimg 5

这将正确运行，因此容器将运行，休眠5秒并退出。正如我们在这个示例中看到的，docker只是将图像名称后面的内容添加到入口点二进制docker runtestimg<my_cmd>。如果我们想将默认值（默认参数）传递给入口点，会发生什么？在这种情况下，我们只需要在CMD部分中指定它，例如：

From ubuntu
ENTRYPOINT ["sleep"]
CMD ["10"]

在这种情况下，如果用户没有传递任何参数，容器将使用默认值（10）并将其传递给入口点睡眠。

现在，让我们只使用CMD并省略ENTRYPOINT定义：

FROM ubuntu
CMD ["sleep", "5"]

如果我们重建并运行此图像，它将基本休眠5秒。

总之，您可以使用ENTRYPOINT使容器充当可执行文件。您可以使用CMD为入口点提供默认参数，或者在启动容器时运行自定义命令，该命令可以由用户从外部重写。

根据docker文档，

CMD和ENTRYPOINT指令都定义执行什么命令当运行容器时。很少有规则描述合作。Dockerfile应至少指定CMD或ENTRYPOINT命令之一。将容器用作可执行文件时，应定义ENTRYPOINT。CMD应用作为ENTRYPOINT命令或在容器当使用可选参数运行容器时，CMD将被重写。

下表显示了对不同ENTRYPOINT/CMD组合执行的命令：

--无入口点

╔════════════════════════════╦═════════════════════════════╗
║ No CMD                     ║ error, not allowed          ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD ["exec_cmd", "p1_cmd"] ║ exec_cmd p1_cmd             ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD ["p1_cmd", "p2_cmd"]   ║ p1_cmd p2_cmd               ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ /bin/sh -c exec_cmd p1_cmd  ║
╚════════════════════════════╩═════════════════════════════╝

--入口点执行_入口p1_入口

╔════════════════════════════╦══════════════════════════════════╗
║ No CMD                     ║ /bin/sh -c exec_entry p1_entry   ║
╟────────────────────────────╫──────────────────────────────────╢
║ CMD ["exec_cmd", "p1_cmd"] ║ /bin/sh -c exec_entry p1_entry   ║
╟────────────────────────────╫──────────────────────────────────╢
║ CMD ["p1_cmd", "p2_cmd"]   ║ /bin/sh -c exec_entry p1_entry   ║
╟────────────────────────────╫──────────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ /bin/sh -c exec_entry p1_entry   ║
╚════════════════════════════╩══════════════════════════════════╝

--入口[“exec_entry”，“p1_entry“]

╔════════════════════════════╦═════════════════════════════════════════════════╗
║ No CMD                     ║ exec_entry p1_entry                             ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD ["exec_cmd", "p1_cmd"] ║ exec_entry p1_entry exec_cmd p1_cmd             ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD ["p1_cmd", "p2_cmd"]   ║ exec_entry p1_entry p1_cmd p2_cmd               ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd  ║
╚════════════════════════════╩═════════════════════════════════════════════════╝

我将把我的答案作为一个例子，1这样可以帮助你更好地理解其中的区别。

假设我们希望创建一个图像，该图像在启动时始终运行sleep命令。我们将创建自己的映像并指定一个新命令：

FROM ubuntu
CMD sleep 10

构建图像：

docker build -t custom_sleep .
docker run custom_sleep
# sleeps for 10 seconds and exits

如果我们想改变秒数怎么办？我们必须更改Dockerfile，因为该值是硬编码的，或者通过提供不同的值来重写该命令：

docker run custom_sleep sleep 20

虽然这是可行的，但这不是一个好的解决方案，因为我们有一个冗余的“睡眠”命令。为什么冗余？因为容器的唯一目的是睡眠，所以必须显式指定睡眠命令有点尴尬。

现在，让我们尝试使用ENTRYPOINT指令：

FROM ubuntu
ENTRYPOINT sleep

此指令指定容器启动时将运行的程序。

现在我们可以运行：

docker run custom_sleep 20

默认值如何？嗯，你猜对了：

FROM ubuntu
ENTRYPOINT ["sleep"]
CMD ["10"]

ENTRYPOINT是将要运行的程序，传递给容器的值将附加到该程序。

可以通过指定--ENTRYPOINT标志，后跟要使用的新入口点来覆盖ENTRYPOINT。

不是我的，我曾经看过一个提供了这个例子的教程

Dockerfile最佳实践的官方文档很好地解释了这些差异。Dockerfile最佳实践

CMD:

CMD指令应用于运行映像中包含的软件以及任何参数。CMD几乎应始终以CMD[“executable”，“param1”，“param2”…]的形式使用。因此，如果映像用于服务，例如Apache和Rails，则可以运行类似CMD[“apache2”，“-DFOREGROUND”]的命令。实际上，对于任何基于服务的图像，都建议使用这种形式的说明。

入口点：

ENTRYPOINT的最佳用法是设置映像的主命令，允许该映像像运行该命令一样运行（然后使用CMD作为默认标志）。

我已经阅读了所有答案，我想总结一下，以便更好地理解以下内容：

首先，在容器中执行的整个命令包括两部分：命令和参数

ENTRYPOINT定义当容器已启动（用于命令）CMD指定传递给ENTRYPOINT的参数（用于参数）

在《Kubernetes In Action》一书中指出了一个重要的注意事项。（第7章）

尽管可以使用CMD指令指定命令要在运行映像时执行，正确的方法是执行通过ENTRYPOINT指令，并仅在以下情况下指定CMD希望定义默认参数。

你也可以阅读这篇文章，以简单的方式获得很好的解释

CMD和ENTRYPOINT之间的直觉差异：

ENTRYPOINT：容器启动时运行的命令。CMD：容器启动时运行的命令，或ENTRYPOINT的参数（如果指定）。

是的，这令人困惑。

在运行docker run时，可以覆盖其中任何一个。

CMD和ENTRYPOINT之间的差异示例如下：

docker run -it --rm yourcontainer /bin/bash            <-- /bin/bash overrides CMD
                                                       <-- /bin/bash does not override ENTRYPOINT
docker run -it --rm --entrypoint ls yourcontainer      <-- overrides ENTRYPOINT with ls
docker run -it --rm --entrypoint ls yourcontainer  -la  <-- overrides ENTRYPOINT with ls and overrides CMD with -la

有关CMD和ENTRYPOINT之间差异的更多信息：

docker run的参数（例如/bin/bash）会覆盖我们在Dockerfile中编写的任何CMD命令。

ENTRYPOINT不能在运行时被docker run[args]等正常命令覆盖。docker运行结束时的args[args]作为ENTRYPOINT的参数提供。通过这种方式，我们可以创建一个像ls这样的普通二进制文件的容器。

因此，CMD可以作为ENTRYPOINT的默认参数，然后我们可以从[args]重写CMD参数。

ENTRYPOINT可以用--ENTRYPOINT重写。