docker stop 是自动化部署中用于优雅终止旧容器的关键命令，位于部署前准备阶段，通过默认10秒graceful shutdown释放端口等资源，并支持超时调整、信号控制、命名/标签精准操作及健康检查联动。

在自动化部署中，DockerStop本身并不是一个独立命令，而是 docker stop 的常见误写或简写习惯。真正起作用的是 docker stop —— 它负责优雅终止正在运行的容器，是部署流程中关键的“清理”环节。用好它，能避免端口冲突、数据残留、服务启停错乱等问题。

明确 stop 在部署流水线中的定位

docker stop 通常出现在部署前的准备阶段，而非部署后。它的核心作用是：为新版本容器腾出资源（如绑定端口、卷挂载点、网络别名），同时保障旧容器有时间完成正在处理的请求（通过默认 10 秒 graceful shutdown）。

• 典型顺序：stop 旧容器 → 拉取/构建新镜像 → run 新容器 → （可选）健康检查 → 清理旧镜像
• 不建议在 CI/CD 脚本里直接用 docker kill 替代，除非确认无状态且可中断
• 若使用 Docker Compose，对应操作是 docker compose down（自动 stop + remove）或 docker compose stop（仅停止）

控制超时与信号，避免僵死或强制杀进程

docker stop 默认发送 SIGTERM，等待 10 秒后若容器未退出，再发 SIGKILL。这个行为可调，对不同应用很关键：

• Web 服务（如 Nginx、Spring Boot）：通常几秒内可优雅关闭连接，保持默认 10s 即可
• 批处理或长事务容器：需延长超时，例如 docker stop --time=60 my-app
• 自定义终止逻辑：在镜像的 ENTRYPOINT 或应用代码中捕获 SIGTERM，执行清理（如关闭数据库连接、刷盘缓存）

结合容器命名与标签，精准停止目标实例

自动化脚本中避免用 docker stop $(docker ps -q) 这类模糊操作——容易误停其他环境容器。推荐方式：

• 启动时指定唯一名称：docker run --name app-prod-v2.1 ...，停止时用 docker stop app-prod-v2.1
• 用 label 标记环境与用途：docker run -l env=prod -l service=api ...，再用 docker ps -f "label=env=prod" -f "label=service=api" -q | xargs docker stop
• 在 CI/CD 中，把容器名或 label 值作为变量传入，实现多环境隔离

配合健康检查与依赖管理，提升流程鲁棒性

单纯 stop 不代表部署成功。需和前后步骤联动验证：

• stop 前可加轻量检查：docker ps -f name=app-prod --format "{{.Status}}" | grep -q "Up"，防止重复 stop 报错
• stop 后建议等待几秒再启动新容器，尤其当宿主机资源紧张时
• 若容器依赖数据库等外部服务，stop 本容器前无需停依赖；但整个 stack 升级时，应按依赖拓扑反序 stop（先 app，后 db）