镜像仓库与版本发布：latest、标签和回滚策略

动手前先知道

这篇文章对应的真实任务是：解释为什么生产不要只依赖 latest，如何用日期或 commit 标记镜像，并保留回滚能力。

第一次阅读先弄清“为什么需要这一步、它改变了哪个运行对象、失败时去哪里检查”，再执行命令。命令可以查，运行模型和排障路径才是长期能力。

镜像仓库和版本发布解决的是一个上线问题：服务器到底运行哪一版？如果新版本有问题，怎么回到上一版？

个人项目早期可以先在服务器构建镜像，但只要准备正式上线，就应该开始认真对待版本。

为什么需要版本

如果每次都用：

latest

部署时看起来简单，但排查问题会很难。

例如线上出现 bug，你需要知道：

• 当前前端是哪次构建？
• 当前后端是哪次构建？
• 这次构建对应哪次 Git 提交？
• 上一版镜像还在不在？

所以镜像标签应该能表达版本。

推荐版本格式

个人项目可以选一种简单格式：

日期 + 序号

例如：

xiaoai-blog-api:2026-09-03-001
xiaoai-blog-web:2026-09-03-001

或者：

Git commit hash

例如：

xiaoai-blog-api:8f31c2a
xiaoai-blog-web:8f31c2a

我更建议使用 commit hash，因为它能直接和代码版本对应。

发布流程

推荐流程：

本地测试通过
  ↓
提交代码
  ↓
服务器拉取最新代码
  ↓
构建带版本号的镜像
  ↓
更新 Compose 引用
  ↓
启动新容器
  ↓
健康检查
  ↓
保留上一版用于回滚

镜像仓库怎么选

可选方案：

• Docker Hub。
• 腾讯云 TCR。
• 阿里云镜像仓库。
• 服务器本地构建。

如果只是个人博客，早期服务器本地构建就够用。等部署变频繁、服务器构建慢、需要多台机器时，再接入镜像仓库。

回滚怎么做

回滚的核心是让 Compose 重新指向上一版镜像。

例如：

services:
  api:
    image: xiaoai-blog-api:8f31c2a
  web:
    image: xiaoai-blog-web:8f31c2a

如果新版是 a1b2c3d，旧版是 8f31c2a，回滚就是把镜像标签改回旧版，然后：

docker compose up -d

回滚前要确认数据库迁移有没有破坏兼容。如果数据库结构已经不可逆修改，单纯回滚镜像可能不够。

数据库迁移和镜像版本

上线最危险的不是容器，而是数据库变更。

建议原则：

1. 先备份。
2. 再执行兼容性迁移。
3. 部署新镜像。
4. 验证成功后再清理旧字段或旧逻辑。

不要在没有备份的情况下直接改生产库。

小艾知行录建议

当前阶段建议：

• 测试环境可以继续用当前简单部署方式。
• 正式上线前，每次发布保留上一版镜像。
• 重要数据库迁移前必须备份。
• 部署日志记录版本号、时间、操作人、结果。

这样个人项目不会太重，但遇到问题有路可退。