Docker Swarm支持真正多节点平滑升级，需启用Swarm模式、使用docker stack部署、配置replicas≥2、update_config.order为start-first、健康检查及published端口映射，并通过docker service ps和logs监控滚动更新全过程。
单纯用 docker-compose 无法实现真正意义上的多节点平滑升级——它本质是单机编排工具，不管理跨主机调度、服务发现或分布式健康状态同步。所谓“多节点环境下的平滑升级”，实际必须依赖 Docker Swarm 模式（即 docker stack）或迁移到 Kubernetes 等集群编排平台。下面直接讲清楚怎么做、为什么这么配置、以及常见踩坑点。
必须启用 Swarm 模式才能跨节点滚动更新
本地执行 docker-compose up -d 始终只在当前机器运行，即使你有多个物理/虚拟节点，它也不会自动分发容器。要让服务实例分布在多台机器上并支持滚动替换，第一步是初始化 Swarm 集群：
- 在任一节点执行
docker swarm init --advertise-addr <本机IP>，获取 join token - 其余节点用
docker swarm join --token <xxx> <manager-ip>:2377加入 - 确认节点状态：
docker node ls显示Ready且角色为worker或manager
之后所有部署必须改用 docker stack deploy -c docker-compose.yml myapp，而非 docker-compose up。只有 stack 才会把 deploy 配置交由 Swarm 调度器执行。
docker-compose.yml 中关键配置项缺一不可
Swarm 模式下，以下字段共同决定是否能零中断升级：
-
replicas：至少设为
2。单副本时，即使配置start-first，新容器启动期间旧容器虽未停，但 Swarm 的内置 DNS 和负载均衡不会将流量分给“正在启动中”的新实例，实际仍可能丢请求 -
update_config.order：必须显式写
start-first。默认是stop-first，即先停旧再启新，必然中断 -
healthcheck：不是可选装饰。Swarm 依赖它判断新容器是否真正就绪——只有状态变为
healthy，才会把旧实例从服务端点中剔除。测试命令如["CMD", "curl", "-f", "http://localhost:8080/health"]，且需确保应用监听0.0.0.0而非127.0.0.1 -
ports：避免直接映射宿主机端口（如
- "80:80"）。多节点环境下，宿主机端口冲突会导致新容器启动失败。应使用published+target模式，或完全依赖 Swarm 内网通信，前端用 Traefik/Nginx 做统一入口
执行升级时用正确命令，避免全量重建
修改镜像标签后，不要运行 docker stack deploy 全量重推——它会重建所有服务，哪怕只改了一个 image 字段，也可能因依赖关系触发数据库等无关服务重启。稳妥做法是：
- 先推送新镜像到仓库：
docker push myapp:v2.1 - 更新
docker-compose.yml中对应服务的image字段 - 执行：
docker stack deploy -c docker-compose.yml myapp --resolve-image always - 加
--resolve-image always强制拉取最新镜像，避免缓存旧版本 - 监控进度：
docker service ps myapp_web查看任务状态，running且Running时间递增表示新实例已就绪
验证与回滚必须提前准备
升级不是执行完命令就结束，关键在可观测性和快速响应：
- 健康检查失败时，Swarm 默认行为是不断重试新容器，直到超时（默认 30 秒），然后按
failure_action处理。建议显式配置：failure_action: rollback，出错自动切回上一版 - 日志不能只看终端输出，要用
docker service logs -f myapp_web实时跟踪，重点观察health check passed和shutting down时间戳是否错开 - 生产环境务必接入指标系统（如 Prometheus），监控
service_tasks_running和http_request_duration_seconds，P99 延迟突增或错误率超过 0.1% 应立即人工介入 - 回滚只需改回镜像标签再执行一次
docker stack deploy，整个过程通常在 10 秒内完成
