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

CMD:

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

入口点：

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

•Dockerfile应至少指定一条CMD或ENTRYPOINT指令

•仅使用Dockerfile中的最后一个CMD和ENTRYPOINT

•将容器用作可执行文件时，应定义ENTRYPOINT

•您应该使用CMD指令来定义默认参数定义为ENTRYPOINT的命令或用于在容器

•使用替代参数运行容器时，CMD将被覆盖

•ENTRYPOINT设置每次容器是使用图像创建的

•如果您将ENTRYPOINT与CMD结合，则可以从CMD中删除可执行文件并且只留下将传递给ENTRYPOINT的参数

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

Docker有一个默认入口点/bin/sh-c，但没有默认命令。

当你这样运行docker时：docker运行-i-t ubuntu bash入口点是默认的/bin/sh-c，图像是ubuntu，命令是bash。

该命令通过入口点运行。即，实际执行的是/bin/sh-cbash。这允许Docker依靠shell的解析器快速实现RUN。

后来，人们要求能够定制这个，所以引入了ENTRYPOINT和--ENTRYPOINT。

在上面的示例中，图像名称ubuntu之后的所有内容都是命令，并传递给入口点。当使用CMD指令时，它就像您在执行docker运行-i-t ubuntu<cmd>入口点的参数为＜cmd＞。

如果改为键入以下命令docker run-i-t ubuntu，也会得到相同的结果：bash shell将在容器中启动，因为在ubuntu Dockerfile中指定了默认CMD：CMD[“bash”]。

当一切都传递到入口点时，您可以从图像中获得非常好的行为@Jiri示例很好，它展示了如何将图像用作“二进制”。当使用[“/bin/cat”]作为入口点，然后执行docker运行img/etc/passwd时，您会发现，/etc/passwd是一个命令，并被传递到入口点，因此最终执行的结果只是/bin/cat/etc/passwd。

另一个示例是将任意cli作为入口点。例如，如果您有一个redis映像，而不是运行docker run redisig redis-H something-u to get key，您可以简单地使用ENTRYPOINT[“redis”，“-H”，“something”，“-u”，”toto“]，然后像这样运行以获得相同的结果：docker run reisig get key。

Dockerfile文件中提到的CMD命令可以通过docker run命令覆盖，而ENTRYPOINT不能覆盖。

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

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

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

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

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

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

大多数人在这里都解释得很好，所以我不会重复所有的答案。但为了得到一个好的感觉，我建议自己通过查看容器中的流程来测试它。

创建一个小型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”]...

这样，您将很容易看到所有可能的方法之间的差异。