要实现docker compose零停机滚动更新，必须同时满足三个前提：启用swarm模式或compose v2.19+（experimental）、replicas≥2、且配置healthcheck与update_config.order: start-first；否则默认停旧启新导致中断。
要让 Docker Compose 实现真正的自动化滚动更新，关键不是简单改镜像再执行 docker-compose up -d，而是通过声明式配置激活编排层的渐进替换能力——但这仅在特定条件下生效。
必须满足的三大前提条件
缺一不可，否则仍会走“停旧启新”的中断路径：
-
运行模式需启用 Swarm 或使用 Compose v2.19+（开启 experimental）：纯单机
docker-composeCLI 默认不支持滚动逻辑，deploy配置会被静默忽略 -
服务必须设
replicas: ≥2：单副本无法并存新旧实例，即使配了start-first也难保流量不丢 -
必须同时定义
healthcheck+update_config.order: start-first：没有健康检查，系统无法判断新容器是否就绪；没设start-first，默认按stop-first执行，必然中断
核心配置项详解与推荐写法
在 docker-compose.yml 中，滚动行为由 deploy.update_config 控制，建议按生产环境稳定性优先设置：
-
parallelism: 1：每次只更新一个副本，降低风险，适合多数业务 -
delay: 15s：留足时间让新容器完成初始化、建立连接、通过健康检查 -
order: start-first：强制先拉起新容器，等它就绪后再停旧容器 -
failure_action: rollback：配合 Swarm 模式，失败时自动回退到上一版本（需提前推送旧镜像）
健康检查不能只是形式主义
健康检查是滚动更新的“闸门”，配置不当会导致流量切到未就绪实例：
- 测试命令建议用应用真实就绪态检测，例如
["CMD", "curl", "-f", "http://localhost/health"]，而非仅检查端口通不通 -
interval建议设为10s，timeout不短于应用冷启动耗时，retries至少3次，避免偶发抖动误判 - 务必确认应用在返回
200前已完成数据库连接、缓存预热等关键初始化
执行与验证的正确姿势
配置写完不等于万事大吉，操作和观察同样重要：
- 更新命令应使用
docker service update --image myapp:v2.0 myapp（Swarm 模式），而非docker-compose up -d - 用
docker service ps myapp观察任务状态，确认新任务进入Running且旧任务逐步变为Complete或Shutdown - 配合外部监控（如 Prometheus + cURL 检查 /health）验证服务始终可用，响应延迟无尖峰
- 更新后保留旧镜像至少 24 小时，确保回滚通道畅通
