为什么部分Docker镜像会同时设置CMD与ENTRYPOINT参数？

同时配置ENTRYPOINT和CMD的设计思路 #

首先明确Docker的默认规则：当ENTRYPOINT使用exec格式（数组形式，而非shell字符串形式）配置时，CMD的所有内容会被作为默认参数传入ENTRYPOINT指定的程序，这是两者同时配置的核心前提。
这种配置的核心设计思路是执行逻辑与运行参数的解耦：

• ENTRYPOINT用来定义镜像的核心固定行为，不会被用户执行docker run时末尾附加的参数覆盖，只有明确加--entrypoint参数时才会修改
• CMD用来定义核心行为的默认参数，用户可以通过run命令末尾加参数的方式轻松替换
  这种设计既保证了镜像的核心用途不会被误改，又保留了足够的自定义灵活性，避免了用户需要完全重写启动命令的麻烦。

常见适用场景 #

• 工具类镜像制作：比如curl、kubectl、ffmpeg这类纯工具镜像，将ENTRYPOINT设置为工具的二进制文件路径，CMD设置为默认的--help提示。用户直接运行镜像就能看到帮助说明，需要执行具体操作时，直接在run命令后附加参数即可，不需要每次都重复输入工具名。
  示例Dockerfile配置：

  ENTRYPOINT ["kubectl"]
  CMD ["--help"]
  

• 服务类镜像默认配置：比如Nginx、MySQL、Redis这类服务镜像，ENTRYPOINT固定为服务启动程序，CMD设置为默认的启动参数。用户可以直接使用默认配置启动服务，也可以轻松传入自定义参数修改运行行为，不需要覆盖整个启动命令。
  示例Dockerfile配置：

  ENTRYPOINT ["nginx"]
  CMD ["-g", "daemon off;"]
  

• 带前置初始化逻辑的镜像：ENTRYPOINT设置为自定义初始化脚本，负责处理权限调整、配置生成、依赖服务等待等前置操作，脚本末尾执行exec "$@"来运行CMD传入的实际服务命令。既保证了初始化逻辑一定会执行，又允许用户自定义要启动的业务命令。
  示例Dockerfile配置：

  ENTRYPOINT ["/opt/init.sh"]
  CMD ["python", "app.py"]
  

内容的提问来源于stack exchange，提问作者Jim