零停机发布依赖deploy.update_config参数（如order: start-first、parallelism、delay）和健康检查，而非docker-compose down；down命令会中断服务，正确做法是用up -d --force-recreate触发滚动更新。
“down 参数”本身不是标准的零停机发布配置项——Docker Compose 中没有 down 参数用于实现零停机；相反，docker-compose down 是**终止并删除容器**的命令，**直接执行会导致服务中断**。真正支撑零停机发布的是 deploy.update_config 下的参数（如 parallelism、delay、order），配合健康检查与滚动更新机制。CI/CD 流水线需避免调用 down，而应驱动 up -d --force-recreate 或 up -d --scale 等安全重建行为。
关键：别用 docker-compose down 做发布
在 CI/CD 流水线中写入 docker-compose down && docker-compose up -d 是典型反模式——这会清空旧容器后再启动新容器，造成秒级甚至分钟级中断。零停机的前提是“新旧共存、平滑过渡”，而非“先停后启”。
-
错误做法：
sh docker-compose down && docker-compose up -d→ 服务中断 -
正确做法：
docker-compose up -d --force-recreate --no-deps <service></service>→ 触发 deploy 配置定义的滚动逻辑 - 仅当使用 Swarm 模式时，
docker stack deploy才能真正执行声明式滚动更新；纯 Compose 模式下，up -d是唯一支持update_config的命令
必须配置的 deploy.update_config 参数
在 docker-compose.yml 中为服务显式声明部署策略，这是 CI/CD 自动化零停机发布的配置基础：
-
order: start-first：核心开关。确保新容器启动并通过健康检查后，再停止旧容器；若设为stop-first（默认），则先停旧再启新，存在中断窗口 -
parallelism: 1：每次只更新一个副本，适合小流量或高敏感服务；可按需调高（如2），但需确保集群资源冗余 -
delay: 15s：新旧批次间等待时间，必须 ≥ 健康检查start_period+ 首次响应耗时，否则未就绪即切流 -
failure_action: rollback：任一新容器健康检查失败时，自动回退到上一版本镜像，无需人工干预
CI/CD 流水线中的安全发布步骤
以 Jenkins 或 GitHub Actions 为例，将配置与操作对齐：
- 构建新镜像并打标签（如
myapp:v1.2.3），推送至私有 Registry - 更新
docker-compose.yml中对应服务的image:字段（或通过 env 替换变量） - 执行
docker-compose -f docker-compose.prod.yml up -d --force-recreate web→ 触发已配置的update_config - 添加等待脚本：轮询
docker-compose ps web直到新容器状态为Up (healthy) - 集成轻量级 smoke test（如
curl -f http://localhost/health），失败则触发failure_action: rollback或告警暂停流水线
健康检查必须与业务就绪真实对齐
零停机不等于“容器进程起来就转发流量”。健康检查必须反映真实服务能力：
- 避免只检查端口存活（
CMD exit 0），应验证数据库连接、缓存连通性、内部依赖就绪 - 示例（Dockerfile 内）：
HEALTHCHECK --interval=20s --timeout=5s --start-period=40s --retries=3 CMD curl -f http://localhost/actuator/health || exit 1 - 在 Compose 文件中复用该检查：
healthcheck: {test: ["CMD", "curl", "-f", "http://localhost/actuator/health"]} - CI/CD 可在发布前预跑一次 healthcheck 脚本，提前拦截不可用镜像
