父 docker 中的 CMD 是否被子 docker 图像中的 CMD/ENTRYPOINT 覆盖?

Is CMD in parent docker overriden by CMD/ENTRYPOINT in child docker image?

我正试图在 docker 上动手。我知道 CMDENTRYPOINT 用于为 docker 图像指定 start/runnable 命令,并且 CMDENTRYPOINT 覆盖。但我不知道,当父 docker 图像也有 CMDENTRYPOINT 或两者时,它是如何工作的?

子图像是否继承了父图像 docker 的那些值?如果是这样,那么父图像中的 ENTRYPOINT 会覆盖子图像中的 CMD 吗?

我知道 https://github.com/docker/compose/issues/3140 已经讨论过这样的问题。但是,讨论已经很老了(2-3 年前),并没有清楚地回答我的问题。

提前致谢。

ENTRYPOINT 不会覆盖 CMD,它们只是代表结果命令的一部分,并且存在是为了让生活更轻松。每当容器启动时,进程 1 的命令被确定为 ENTRYPOINT + CMD,因此通常 ENTRYPOINT 只是二进制文件的路径,而 CMD 是该二进制文件的参数列表。 CMD 也可以很容易地从命令行覆盖。

所以,再一次,这只是让生活更轻松并使容器的行为就像常规二进制文件一样的东西 - 如果你有 man 容器,你可以将入口点设置为 /usr/bin/man 并将 cmd 设置为 man。因此,如果您只是启动容器,docker 将执行 /usr/bin/man man,但如果您 运行 类似于 docker run man docker,生成的容器命令将是 /usr/bin/man docker - 入口点保持不变,cmd 更改,生成的启动容器的命令只是这些命令的简单合并。

除非被覆盖,否则 ENTRYPOINT 和 CMD 都是从父层(图像)继承的,所以如果你从图像 X 继承并重新定义 CMD,你仍然会有完全相同的 ENTRYPOINT 反之亦然.但是,正如@BMitch 在下面提到的,更改子图像中的 ENTRYPOINT 将有效地重置 CMD。

如果您在子图像中定义 ENTRYPOINT,它将消除 this issue 中标识的 CMD 的值。目标是避免混淆情况,即入口点作为参数传递给您不再想要的命令 运行.

除此特定情况外,ENTRYPOINTCMD 的值是继承的,可以被子映像或同一 Dockerfile 的后续步骤单独覆盖。图像中将只存在其中每一个的一个值,最后定义的值具有优先权。