docker镜像同时配置了entrypoint和CMD,entrypoint指定的是某个命令行工具比如salt,CMD指定的是/bin/bash,那么用docker run启动容器时,会发生什么
当Docker镜像同时配置了ENTRYPOINT
和CMD
时,它们的交互行为如下:
1. ENTRYPOINT
:这是容器启动时运行的命令,它不会被docker run命令行中的参数覆盖,但可以被其参数覆盖。这意味着,无论你在docker run后面跟了什么,ENTRYPOINT指定的命令都会被执行,而你提供的参数会作为该命令的参数。
2. CMD
:这是为ENTRYPOINT提供的默认参数。如果docker run没有提供任何参数,那么CMD中定义的参数会被用作ENTRYPOINT的参数。但是,如果docker run提供了参数,那么这些参数会覆盖CMD中定义的参数。
对于你给出的例子,如果ENTRYPOINT是salt,而CMD是/bin/bash:
- 当使用
docker run
启动容器并且不提供任何额外的参数时,salt
命令会执行,并使用/bin/bash
作为其参数。这很可能不是一个有效的操作,因为salt命令通常不接受/bin/bash
作为参数。 - 如果你在
docker run
后面提供了额外的参数,例如docker run your_image some_salt_arg
,那么salt
命令会执行,并使用some_salt_arg
作为其参数,完全忽略CMD中定义的/bin/bash
。
通常,ENTRYPOINT
和CMD
的这种组合用于创建一个可以灵活配置但又有默认行为的镜像。但是,在这个特定的例子中,这种配置可能并不合理,因为salt和/bin/bash的组合看起来并不符合常规的使用方式。
如果你希望容器默认启动一个bash shell,但同时又允许通过docker run运行其他命令,你可以将ENTRYPOINT
设置为["/bin/bash", "-c"]
,并将CMD
设置为一个默认的bash命令或脚本。这样,当没有提供其他参数时,容器会运行CMD
中定义的命令;当提供了其他参数时,这些参数会作为bash命令执行。
覆盖镜像中的entrypoint
docker run --entrypoint /bin/bash myimage