如果没有提供入口点，并且在没有可执行文件的情况下以Exec形式使用CMD，那么在Docker中执行什么？

Question

引用CMD的码头文件的话：

CMD教学有三种形式： CMD "param1"，"param2“ 这些默认值可以包括一个可执行文件，或者可以省略可执行文件，，在这种情况下，您还必须指定一个入口点指令。

再次引用Docker文档，这一次来自了解CMD和入口点是如何相互作用的

下表显示了对不同的切入点/ CMD组合执行什么命令：

                            No ENTRYPOINT
CMD [“p1_cmd”, “p2_cmd”]    p1_cmd p2_cmd

我不明白我复制的交集在上面。我希望CMD [“p1_cmd”, “p2_cmd”]和No ENTRYPOINT的交集是error, not allowed (就像No、intersection一样)，但是表中说p1_cmd p2_cmd会被执行。我假设p1_cmd和p2_cmd是参数，比如-t -a之类的。

那么在这种状态下执行什么呢？这是否意味着参数成为可执行文件？

Answer 1

最简单的设想方法是ENTRYPOINT和CMD都定义单词列表，最后的命令是通过将这两个列表连接在一起来构造的。Docker无法知道CMD列表的第一个单词是否实际上是可执行文件。

在启动容器时，所有这三个命令都运行完全相同的命令：

FROM busybox
ENTRYPOINT ["/bin/ls"]
CMD ["-lrt", "/"]

FROM busybox
ENTRYPOINT []
CMD ["/bin/ls", "-lrt", "/"]

FROM busybox
ENTRYPOINT ["/bin/ls", "-lrt", "/"]
CMD []

我的一般经验是，CMD本身就应该是一个结构良好的命令。这有两个很好的原因：docker run --rm -it imagename sh经常有用，看看您的映像构建过程中产生了什么；还有一种有用的模式，将ENTRYPOINT设置为一个脚本，该脚本执行一些第一次设置，然后将exec "$@"设置为运行CMD。(将两者结合在一起，在第一次安装程序运行后，您将得到一个调试shell。)

# good
CMD ["/app/myapp", "--foreground"]

# good
ENTRYPOINT ["wait-for-it.sh", "db:5432", "--"]
CMD ["/app/myapp", "--foreground"]

# hard to provide an alternate command or an ENTRYPOINT wrapper
ENTRYPOINT ["/app/myapp"]
CMD ["--foreground"]

出于实际目的，ENTRYPOINT必须是JSON数组形式，不能使用sh -c包装器。正如文档所指出的，如果ENTRYPOINT是一个简单的命令，那么CMD就会被忽略；如果它有一个显式的sh -c包装器，那么带有附加参数的交互就不明显了。

# just prints an empty line
FROM busybox
ENTRYPOINT /bin/echo
CMD ["one", "two", "three", "four"]

# just prints an empty line
FROM busybox
ENTRYPOINT ["/bin/sh", "-c", "/bin/echo"]
CMD ["one", "two", "three", "four"]

实际上，ENTRYPOINT作为一个裸字符串本身并不阻止CMD；但是最终的/bin/sh -c 'some command' arg arg以一种不明显的方式在命令中设置$0、$1等。

# prints "three"
FROM busybox
ENTRYPOINT echo $2
CMD ["one", "two", "three", "four"]

# prints "-c"
FROM busybox
ENTRYPOINT echo $1
CMD one two three four