容器升级与回滚：把「出事能退回去」变成流程

容器升级最危险的不是升级本身，是「升完发现不对，但数据库已经迁移了」。

可回滚的前提是：镜像版本可控、数据变更向后兼容、回滚步骤提前演练过。

先说结论

镜像固定 tag、升级前备份数据库、迁移脚本要能兼容旧版本。 三件事做到，回滚才是真的。

• 升级前记录当前镜像 tag 与 digest
• 数据库先备份并验证可恢复
• 有 schema 变更时先做向后兼容的设计
• 回滚脚本提前写好并演练

先把问题说清楚

容器化的优势之一就是回滚快：改回 tag 重启即可。但如果数据已经按新版本结构写入，旧版本可能读不了。

所以升级流程必须包含「数据兼容性」这一步，而不是只看服务能不能起来。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• 记录当前版本：docker inspect 看 image digest
• 备份数据并校验（按存储快照或逻辑导出）
• 拉新镜像，先在临时端口起一份做冒烟测试
• 切换流量，观察错误率与日志 15 分钟
• 异常时改回旧 tag 重启，并确认数据可读

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 用 latest：升级了但不知道升到哪个版本
• 只备份容器不备份数据
• schema 迁移不可逆还硬上
• 回滚时不检查数据，旧版本读到新结构直接崩

最后补两句

升级的成熟度不看成功率，看失败时能不能在十分钟内回到上一个已知良好状态。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。