容器镜像重建是什么
容器内不推荐就地更新软件包：标准做法是更新基础镜像 → 重建应用镜像 → 扫描 → 滚动发布。这条路径保证了构建产物不可变、可追溯、可回滚。部署时用镜像摘要（digest）固定引用，避免标签漂移导致不同节点拉到不同内容。就地进容器打补丁会破坏不可变性，重建与回滚都无从谈起。
基本信息
| 基本原则 | 构建产物不可变：修复等于出一个新镜像 |
|---|---|
| 引用方式 | 部署使用 digest 固定，避免 tag 漂移 |
| 清理策略 | 保留回滚所需的最近若干标签，其余按策略回收 |
| 验证环节 | 重建后扫描，再滚动发布并观察 |
重建流程
重建流程
docker pull base-image:tag # 获取含修复的新基础镜像
docker build --no-cache -t app:2026-10-12 . # 重新构建（必要时禁用缓存）
trivy image --severity HIGH,CRITICAL app:2026-10-12 # 重建后扫描
docker push registry.example.com/app:2026-10-12 # 推送并滚动更新
# 保留旧标签与 digest 用于回滚，按批次观察后再全量典型使用场景
- 基础镜像发布安全修复后重建业务镜像
- 语言运行时或依赖升级：修改 Dockerfile 后重建
- 批量资产治理：对同一基础镜像构建的全部业务镜像统一重建
- 回滚准备：发布前确认旧镜像仍可用并被保留
- 合规要求：证明镜像内容与扫描结果、构建记录可追溯
常见问题与处置
| 问题 | 后果 | 处置 |
|---|---|---|
| 用 latest 标签 | 不同节点内容不一致 | 改用固定标签 + digest |
| 就地进容器改包 | 不可变性被破坏 | 改为重建新镜像 |
| 构建缓存未失效 | 基础镜像更新未生效 | 拉取基础镜像或禁用缓存 |
| 旧标签被清理 | 无法回滚 | 保留回滚所需标签 |
『进容器手动 yum update』会破坏不可变性：容器重启后改动丢失，重建与回滚都无从谈起，问题还会在下次发布时重现。
重建后要重新扫描：新基础镜像可能引入其他问题，同时应确认扫描对象与将要部署的镜像 digest 完全一致。