容器生命周期如何处理容器升级失败时的快速回滚

容器升级失败回滚的关键是用已验证旧镜像重建服务，而非撤销操作；需提前打语义化标签、预拉取镜像、编排工具原子切换、新容器干净退出、回滚后健康检查验证。

容器升级失败时的快速回滚，不是“撤销一次操作”，而是用已验证的旧版镜像重建服务状态。核心在于：回滚动作本身极快，真正决定成败的是升级前是否做了足够准备。

关键不在于“怎么退”，而在于“退得动、退得稳、退得准”

镜像必须带语义化标签，禁用 latest

latest 标签没有版本含义，无法定位上一个稳定版本。每次构建和推送镜像时，必须打明确标签（如 myapp:v2.3.1），并确保该镜像已推送到私有仓库或预拉取到节点本地。

1. 升级前执行 docker pull myapp:v2.2.0，避免回滚时因网络或仓库不可用导致拉取失败
2. 在 docker-compose.yml 或 Kubernetes Deployment 中，所有 image 字段都写死为具体标签，而非 latest

用编排工具实现服务级原子切换

单容器手动 stop/start 容易遗漏依赖、端口冲突或卷挂载问题。真实业务通常含多个组件（web、db、cache），应统一交由编排层处理：

1. Docker Compose：改 image: 字段后执行 docker compose down && docker compose up -d，自动处理网络、卷继承与启动顺序
2. Kubernetes：用 kubectl set image deploy/myapp app=myapp:v2.2.0 或 kubectl rollout undo deployment/myapp，由控制器保证副本集切换的原子性与健康检查闭环
3. Swarm：docker service update --image myapp:v2.2.0 myapp，支持 --rollback 参数直接触发内置回滚

新容器必须干净退出，再启旧版

回滚 ≠ “一边跑新、一边启旧”。若新容器残留（如占用端口、持有数据库连接、未释放锁），旧版本大概率启动失败：

1. 设置合理优雅终止时间：docker stop -t 45 <container> 或 Kubernetes 中配置 terminationGracePeriodSeconds: 45
2. 应用需监听 SIGTERM 并在时限内完成：关闭连接、提交事务、刷盘日志
3. 回滚前确认新容器状态为 Exited (0)，且 netstat -tuln | grep :8080 已无监听

回滚后必须验证服务可用性，不止是容器 running

容器进程起来 ≠ 服务就绪。必须嵌入轻量级验证逻辑：

1. 等待容器状态变为 running 后，发起 curl -f --max-time 8 http://localhost/health
2. 检查返回 HTTP 200 且响应体含 "status":"UP"
3. 若失败，自动标记回滚异常，触发告警，不视为成功

不复杂但容易忽略