Dockerfile 中，`CMD` 和 `ENTRYPOINT`的区别和联系

在 Dockerfile 中，CMD 和 ENTRYPOINT 均用于定义容器启动时的行为，但二者的设计目的和交互逻辑有显著差异。以下是核心区别及典型使用场景的分析[⁹]：

基础概念与设计目标

特性	CMD	ENTRYPOINT
定义	指定容器启动时的默认命令	定义容器的主执行程序/入口点
核心作用	提供默认操作（可被覆盖）	固定容器的核心身份（不易被覆盖）
比喻	“菜单推荐菜” → 可选择其他菜品	“餐厅招牌菜” → 必须上这道菜

关键行为差异

1. 覆盖性

• CMD：易被覆盖。若 docker run 命令末尾提供新命令（如 bash），则完全替换 CMD 的内容[³][⁶]。

  # 假设 Dockerfile 中定义了 CMD ["python", "app.py"]
  docker run my-image bash  # 实际执行 bash，而非 python app.py
  

• ENTRYPOINT：难被覆盖。需通过 --entrypoint="" 显式修改，否则始终执行其定义的命令[⁴][⁶]。

  # 假设 Dockerfile 中定义了 ENTRYPOINT ["/bin/echo"]
  docker run --entrypoint="/bin/ls" my-image /tmp  # 执行 ls /tmp
  

2. 参数传递机制

• 单独使用 CMD：直接执行命令及其参数[³]。

  CMD ["grep", "root"]  # 执行 grep root
  

• 单独使用 ENTRYPOINT：仅执行命令本身，无额外参数（除非手动添加）[⁴]。

  ENTRYPOINT ["/bin/echo"]  # 执行 echo（无参数时输出空行）
  

• 组合使用（ENTRYPOINT + CMD）：CMD 内容作为 ENTRYPOINT 的参数[⁴][⁶]。

  ENTRYPOINT ["/bin/echo"]
  CMD ["hello,world"]  # 最终执行 echo hello,world
  

  此时若运行 docker run my-image hello,code，则输出 hello,code（CMD 参数被覆盖）。

3. 信号处理与 PID=1

• ENTRYPOINT (exec 形式)：直接执行可执行文件，确保进程 PID=1，能接收 Linux 信号（如 SIGTERM）[⁸][⁹]。
• CMD 或 ENTRYPOINT (shell 形式)：通过 shell 执行，导致 PID≠1，可能无法响应信号[⁸]。

使用场景建议

需求	推荐方案	示例
允许用户自定义命令	仅用 CMD	CMD ["bash"]
固定主程序但允许参数调整	ENTRYPOINT + CMD（CMD 提供默认参数）	ENTRYPOINT ["python"]; CMD ["app.py"]
复杂初始化后执行主程序	ENTRYPOINT 指向脚本，脚本末尾用 exec "$@" 传递参数[7][9]	ENTRYPOINT ["/init.sh"]
调试容器环境	临时覆盖 ENTRYPOINT 为交互式终端	docker run --entrypoint "/bin/bash"

最佳实践

1. 优先使用 exec 形式：避免 shell 形式导致的信号丢失问题[⁸][⁹]。

   # 推荐写法（exec 形式）
   ENTRYPOINT ["/usr/bin/myapp"]
   CMD ["--config", "/etc/config"]
   
   # 不推荐写法（shell 形式）
   # ENTRYPOINT /usr/bin/myapp  # 通过 sh -c 执行，PID≠1
   

2. 组合使用场景：多数官方镜像采用 ENTRYPOINT + CMD 模式，既固定主程序又提供合理默认参数[⁶][⁹]。

   # Nginx 镜像的典型配置
   ENTRYPOINT ["/docker-entrypoint.sh"]  # 处理信号、创建配置文件等
   CMD ["nginx", "-g", "daemon off;"]    # 默认参数
   

综上，CMD 提供灵活性，适合默认行为；ENTRYPOINT 确保确定性，适合固定核心程序。二者结合可实现既稳定又可定制的容器行为。