生产环境平滑升级docker容器的核心是实现应用零停机更新，而非升级docker引擎本身；需配置healthcheck、deploy.update_config.order: start-first、replicas≥2，并避免端口冲突、混用镜像与配置等常见错误。
生产环境平滑升级 Docker 容器，核心不是“升级 Docker 本身”，而是**用 Docker 实现应用的零停机更新**。真正要保障的是业务服务不中断，而不是 Docker 引擎版本升级（那属于运维维护范畴，需单独计划停机窗口）。下面分两类场景说清楚：
一、应用容器平滑升级（高频刚需）
这是绝大多数人实际需要的：镜像更新了，怎么让新版本上线时不丢请求？关键靠 docker-compose + 滚动更新配置，不是手动 stop/start。
-
必须写 healthcheck：容器内要能自检就绪，比如
curl -f http://localhost:80/health。没它，编排器不知道新容器是否真能处理流量 -
必须设 deploy.update_config：尤其
order: start-first—— 先启新容器，等它健康再停旧的；默认是 stop-first，必然中断 - 副本数至少为 2：单实例即使配了 start-first，DNS 或负载均衡轮询延迟也可能导致短暂 502/超时；双实例才能真正实现“新旧共存、无缝切换”
-
避免端口冲突：别在
ports下硬绑宿主机端口（如- "80:80"），否则新旧容器抢端口会启动失败；改用expose+ 内部网络通信，或由反向代理（Nginx/HAProxy）统一入口 -
更新时锁定服务：只升 web 层？用
docker-compose up -d --no-deps web，避免连带重启 db、cache 等无关依赖
二、Docker 引擎自身升级（低频维护）
升级 docker-ce 本身无法做到完全无感知——它是个系统级守护进程。但可以最小化影响：
- 避开业务高峰：选在凌晨或低峰期，提前通知上下游
- 确认容器运行时兼容性：新版 Docker 对 containerd、runc 有要求，升级前查官方兼容矩阵，避免启动失败
-
保留旧数据目录：
/var/lib/docker不用动，新版默认复用；若需迁移，先systemctl stop docker，再拷贝，再启动 -
验证后再切流：升级后跑
docker run --rm hello-world和一个轻量业务镜像，确认 pull、run、network 都正常，再放开线上流量
三、实用避坑提醒
很多“平滑失败”其实卡在细节：
- 健康检查命令写成
curl http://127.0.0.1:80？应用若只监听0.0.0.0就通不过——改成curl -f http://localhost:80或直接nc -z localhost 80 - 资源不够却设了
parallelism: 2？新容器 OOM 退出，健康检查永远 fail，滚动卡死 - 用
docker-compose pull && docker-compose up -d？pull 失败时 up 仍执行，可能混用旧镜像+新配置，行为不可控 - 没加
--timeout 60？健康检查超时默认等很久，命令挂起，自动化流程阻塞
