Docker stop 不能实现蓝绿发布的无感切换，它仅用于清理旧服务；蓝绿切换依赖路由层（如Traefik）动态重定向流量，确保blue与green服务并行运行、健康检查就绪、服务发现解耦。
docker stop 指令本身不能实现蓝绿发布的无感切换，它只是一个强制终止容器的底层命令，与蓝绿部署的核心逻辑相悖。
蓝绿发布的关键在于流量切换而非容器停启。docker stop 会直接杀死容器进程，导致连接中断、请求失败，完全违背“无感”“零停机”的目标。真正起作用的是服务路由层（如 Traefik、Nginx、DNS 或 Swarm 内置 DNS 负载均衡）对两个并行运行的服务（blue 和 green）的流量指向控制。
下面说明实际可行的路径：
蓝绿切换不靠 docker stop，而靠路由重定向
- 蓝色服务（web-blue）和绿色服务（web-green）在 Swarm 中**同时运行**，各自有独立服务名、镜像版本和标签 - 外部入口（如 Traefik）通过 `traefik.http.routers.web.rule=Host(`app.example.com`)` 这类标签识别并路由流量 - 切换动作是修改路由规则（例如更新 Traefik 的配置或动态 API），让所有新请求打到 web-green - 此时 web-blue 仍健康运行，只是不再接收新流量；已有长连接可自然释放，不影响用户体验
什么时候才用 docker stop？——仅用于清理阶段
- 确认 green 服务稳定运行数分钟（监控延迟、错误率、CPU/内存等） - 手动验证核心业务流程无异常 - 然后执行：
-
docker service rm web-blue—— 安全下线旧服务（比docker stop更准确，因它管理整个服务任务集） - 不要对正在提供服务的容器单独执行
docker stop，这会破坏服务发现和负载均衡状态
确保切换真正“无感”的三个前提
- 健康检查必须启用：Swarm 需感知 green 服务是否就绪，例如在 Dockerfile 中定义：HEALTHCHECK --interval=15s --timeout=5s --retries=3 CMD curl -f http://localhost/health || exit 1
- 路由组件支持动态重载：Traefik 可监听 Swarm 事件自动更新路由；若用 Nginx，则需配合脚本热重载配置（nginx -s reload），且确保 upstream 块已预先定义好 blue/green 两组后端
- 服务间调用也要解耦：内部微服务不应硬编码调用 web-blue，而应通过服务名（如 http://web）访问，由 Swarm DNS 解析到当前活跃服务——但这需要配合服务别名或统一网关，不是默认行为
一个典型安全切换流程
- 部署 green 服务（带健康检查、相同副本数、不同服务名）
- 等待所有 green 任务显示 Running 且 Healthy
- 更新 Traefik 路由规则，将 Host 匹配指向 web-green
- 观察 2–5 分钟：日志、指标、人工抽检
- 执行 docker service rm web-blue
整个过程没有一次 docker stop 参与主流程。它只属于运维清理环节，且应由 docker service rm 替代，以保证一致性。
不复杂但容易忽略。
