为什么按 digest 部署
镜像引用有两种写法：仓库名加标签（app/web:1.4.2）和仓库名加摘要（app/web@sha256:…）。标签是可变引用，同一个标签可以被覆盖指向新内容；摘要由镜像内容计算得出，内容变摘要就变。生产部署与回滚写成摘要形式，才能保证「这次部署的就是上次验证过的那一份」，也便于审计时还原当时的实际内容。
基本信息
| 概念 | digest 是内容摘要，tag 是可变引用 |
|---|---|
| 获取 | docker inspect 的 RepoDigests，或 docker images --digests |
| 使用 | docker run 仓库名@sha256:…，编排文件的 image 字段同样支持 |
| 前提 | 镜像已推送到仓库，仅本地构建未推送的镜像没有 RepoDigests |
典型使用场景
- 生产部署固定版本：避免上游把 latest 或版本标签覆盖后，重启拉到的内容变了
- 回滚可复现：发布记录里同时写标签与摘要，回滚时按摘要精确还原
- 审计留痕：摘要与版本评审记录一起归档，事后可核对部署内容
- 供应链对齐：扫描结果与部署对象用同一个摘要串起来，结论可复现
- 多环境一致性：测试与生产部署同一摘要，减少环境间的内容差异
获取摘要并按摘要部署
获取摘要并按摘要部署
# 拉取后读取仓库摘要
docker pull nginx:1.27-alpine
docker inspect -f '{{index .RepoDigests 0}}' nginx:1.27-alpine
# 用摘要部署，内容指向确定
docker run -d --name web nginx@sha256:把上一步输出粘贴到这里
# 编排文件里同样写在 image 字段
# services:
# web:
# image: nginx@sha256:...
# 部署后核对实际使用的摘要
docker inspect -f '{{index .RepoDigests 0}}' web引用方式对照
| 写法 | 可复现性 | 适用场景 |
|---|---|---|
| 仓库名:标签 | 标签可被覆盖，指向可能变化 | 开发与快速迭代 |
| 仓库名@摘要 | 内容唯一，指向固定 | 生产部署、回滚与审计 |
| 本地镜像 ID | 仅本机有效，重启重建后失效 | 本机临时排障 |
摘要固定的是内容，不保证内容安全：漏洞扫描与基线检查仍要单独做，两者互补。
多架构镜像的摘要指向清单列表，不同平台拉取到的是各自变体，跨平台部署时摘要要按目标平台核对。