如何验证镜像的 manifest list 包含正确的架构层 - 问题详情 - 创脉思

解读

在国内云原生面试中，**“多架构镜像”**是高频考点。面试官想确认你是否理解：

镜像仓库里真正保存的是 manifest list（OCI index） 而非单一 manifest；
你能用官方工具快速校验 每个架构层的 digest、mediaType、platform 字段 是否准确；
你熟悉国内网络环境（阿里云 ACR、腾讯云 TCR、华为云 SWR）下的 鉴权与加速 技巧；
你能在 CI 门禁里自动化拦截 “AMD64 镜像被错误标记为 ARM64” 的质量事故。

知识点

manifest list / OCI index：顶层索引，指向不同架构的 manifest
mediaType：application/vnd.docker.distribution.manifest.list.v2+json 或 OCI 等价类型
platform.os/arch/variant：linux/amd64、linux/arm64/v8、linux/arm/v7 等
docker buildx imagetools、crane manifest、regctl manifest 三种零依赖命令行方案
digest 校验：sha256:… 必须与 blobsum 一致，防止层被篡改
国内镜像源：ACR 的“公网免密拉取”与“内网 VPC 域名”差异，需正确配置 docker credential helper
CI 集成：GitHub Actions + buildx、GitLab CI + kaniko、Jenkins + 阿里云 OSS 缓存，均需在门禁步骤里加 “imagetools inspect” 断言

答案

本地准备
安装 docker buildx（≥0.10）与 crane（Go 二进制，国内可用 Goproxy 加速下载）。
配置仓库鉴权：
echo $ALIYUN_ACR_PASSWORD | docker login --username=xxx registry.cn-hangzhou.aliyuncs.com --password-stdin
拉取并解析 manifest list
docker buildx imagetools inspect registry.cn-hangzhou.aliyuncs.com/myapp:v1.2.3 --raw
输出即为原始 JSON，可看到 mediaType 为 manifest list；manifests[] 数组里每个对象包含 digest、platform.os、platform.architecture、platform.variant。
逐层校验
以 linux/arm64/v8 为例，取出 digest：sha256:abcd1234…
继续 inspect 该子 manifest：
crane manifest registry.cn-hangzhou.aliyuncs.com/myapp@sha256:abcd1234
确认 mediaType 为 application/vnd.docker.distribution.manifest.v2+json，并记录 layers[] 里每层的 digest。
用 crane blob 拉取任意一层：
crane blob registry.cn-hangzhou.aliyuncs.com/myapp@sha256:layer5678 | sha256sum
对比输出与 digest 是否一致，完全一致则层未被篡改。

脚本化断言（可直接放进 GitLab CI）

#!/bin/bash
set -e
IMG=registry.cn-hangzhou.aliyuncs.com/myapp:v1.2.3
# 1. 必须存在 linux/amd64 与 linux/arm64
docker buildx imagetools inspect $IMG --format "{{range .Manifests}}{{printf \"%s/%s\n\" .Platform.OS .Platform.Architecture}}{{end}}" | grep -x "linux/amd64"
docker buildx imagetools inspect $IMG --format "{{range .Manifests}}{{printf \"%s/%s\n\" .Platform.OS .Platform.Architecture}}{{end}}" | grep -x "linux/arm64"
# 2. 每个子 manifest 的层 digest 可拉取且校验通过
for arch in amd64 arm64; do
  MANIFEST_DIGEST=$(docker buildx imagetools inspect $IMG --format "{{range .Manifests}}{{if eq .Platform.Architecture \"$arch\"}}{{.Digest}}{{end}}{{end}}")
  crane manifest $IMG@$MANIFEST_DIGEST | jq -r '.layers[].digest' | while read LAYER; do
    crane blob $IMG@$LAYER | sha256sum | grep -q "^${LAYER#sha256:}"
  done
done
echo "✅ manifest list 架构层校验全部通过"

加分项
若使用 Harbor 2.5+，可打开“镜像签名与漏洞扫描”策略，在 Webhook 中强制 cosign verify 后再进行上述步骤，形成 “签名→多架构→层校验” 三级门禁。

拓展思考

“一镜像一平台”误区：国内很多项目图省事，只在 CI 里 build 一次 amd64，然后手动 docker tag 成 arm64，造成 manifest list 指向同一 digest。面试官会追问如何发现：答案是用 imagetools inspect 看两个架构的 digest 是否相同，或直接用 qemu 静态模拟 启动容器，uname -m 暴露真实架构。
跨云迁移场景：客户从阿里云 ACR 同步到华为云 SWR，需重新计算层摘要。若使用 “层挂载” 接口（Docker Registry v2 的 Mount Blob），必须保证 digest 不变，否则需全量重新推送。此时可用 regctl copy --digest-algorithm sha256 确保一致性。
边缘计算裁剪：ARM64 边缘节点内存只有 512 MiB，需验证 manifest list 里是否包含 alpine+upx 压缩的静态 busybox 层。可在 CI 中增加 “层大小阈值” 断言：
crane manifest $IMG@$MANIFEST_DIGEST | jq -r '.layers[].size' | awk '{s+=$1} END {if(s>30*1024*1024) exit 1}'
超过 30 MiB 直接拒绝合并到 release 分支，保证边缘拉取速度。
未来趋势：OCI 1.1 引入 “artifactType” 与 “subject” 字段，可把 SBOM、扫描报告、签名 作为附属 artifact 挂到同一 repo。下一轮面试可能让你验证 “多架构镜像 + SBOM” 的复合 manifest，思路相同，只是 mediaType 换成 application/vnd.cyclonedx+json，同样用 crane manifest 解析即可。