denied: unknown manifest class for application/vnd.oci.empty.v1+json

Docker 镜像明明构建成功，为什么推送到阿里云 ACR 却失败了？深入剖析 OCI Manifest 兼容问题

在这里插入图片描述

DockerAttestation与OCI仓库流程图-1.png Docker_Attestation_与_OCI_仓库流程图-1.png

作者：王仕宇 | JavaPub

最近我在维护一套基于 GitHub Actions、Docker Buildx 和阿里云 ACR 的 CI/CD 自动化部署流程时，遇到了一个很有意思的问题。

Docker 镜像构建没有报错，镜像层也上传成功，甚至连 Manifest 都显示 done，但整个流水线最后还是失败了。

最关键的报错只有一句：

denied: unknown manifest class for application/vnd.oci.empty.v1+json

这个错误看起来很陌生，而且具有迷惑性。它不是常见的网络超时、权限不足或者镜像构建失败。

问题实际上涉及 Docker BuildKit 的构建证明机制、OCI 镜像规范，以及镜像仓库对不同 Manifest 格式的兼容性。

这篇文章，我想从这次真实故障出发，把整个问题讲透。

一、故障现场：为什么所有步骤都显示成功，最后却失败了？

先看看当时 CI/CD 的关键日志。

为了避免暴露实际项目，以下仓库地址、镜像名称、版本及摘要均已脱敏，错误内容保持原样。

#21 exporting manifest sha256:<redacted> done
#21 exporting config sha256:<redacted> done
#21 exporting attestation manifest sha256:<redacted> done
#21 exporting manifest list sha256:<redacted> done

#21 pushing layers
#21 ...

#22 [auth] example/demo-service:pull,push token
#22 DONE 0.0s

#21 exporting to image
#21 pushing layers 9.0s done

#21 pushing manifest for registry.example.com/example/demo-service:v1
#21 pushing manifest for registry.example.com/example/demo-service:v1 1.4s done

#21 ERROR: failed to push registry.example.com/example/demo-service:v1:
denied: unknown manifest class for application/vnd.oci.empty.v1+json

ERROR: failed to build: failed to solve:
failed to push registry.example.com/example/demo-service:v1:
denied: unknown manifest class for application/vnd.oci.empty.v1+json

make: *** [Makefile:49: docker-release] Error 1
Error: Process completed with exit code 2.

这段日志中，我认为有五个值得关注的细节。

1. `exporting manifest` 成功

#21 exporting manifest ... done

这说明 BuildKit 已经成功生成了镜像 Manifest。

Manifest 本质上是一份 JSON 元数据文件，用来描述镜像包含哪些层、对应哪个配置文件，以及这些内容的哈希摘要。

它不是 Dockerfile，也不是镜像文件本身，而是镜像内容的索引与描述信息。

2. `exporting attestation manifest` 成功

#21 exporting attestation manifest ... done

这是本次故障最重要的线索。

Attestation 可以理解为附着在镜像上的构建证明信息。

例如，镜像由什么构建工具生成、构建过程使用了什么参数、构建来源是什么。

它不属于容器运行时必须使用的文件系统内容。

也就是说，我们平时执行：

docker run example/demo-service:v1

并不需要依赖 Provenance Attestation 才能启动应用。

但 BuildKit 在向 Registry 推送镜像时，可以把这些证明信息一并上传。

3. `pushing layers` 成功

#21 pushing layers 9.0s done

这说明相关镜像层的上传过程已经完成。

因此，排查重点不应该首先放在 Dockerfile 语法、Go 编译过程或者普通文件层上传失败上。

当然，镜像层上传成功不代表整个镜像已经成功发布。

4. `pushing manifest` 显示 done

#21 pushing manifest ... 1.4s done

这是最容易误导开发者的地方。

done 只代表对应操作步骤已经完成，并不意味着 Registry 已经接受整个镜像索引及所有关联对象。

构建过程中可能会上传多个 Manifest 对象。

只要其中某个对象不被仓库支持，最终仍然可能失败。

5. `unknown manifest class` 是最终失败原因

denied: unknown manifest class for application/vnd.oci.empty.v1+json

这里出现了一个非常关键的字符串：

application/vnd.oci.empty.v1+json

它不是随意生成的错误描述，而是 OCI 规范中定义的一个 Media Type。

看到这里，问题已经从普通的 Docker 构建错误，转向了 OCI 制品格式与 Registry 兼容性问题。

二、要理解这个错误，先搞清楚 Docker 镜像到底是什么

我们每天都在使用 Docker 镜像，但很多时候会把镜像简单理解成一个打包好的文件系统。

实际上，现代 Docker 镜像是由多种对象共同组成的。

最基本的三个部分是：

Image Manifest
Image Config
Image Layers

可以简单理解为下面这套结构。

Docker Image
│
├── Image Manifest
│   │
│   ├── Image Config
│   │   ├── 环境变量
│   │   ├── 启动命令
│   │   ├── 工作目录
│   │   └── 其他配置
│   │
│   └── Image Layers
│       ├── Layer 1
│       ├── Layer 2
│       └── Layer 3
│
└── 通过 Digest 引用各个对象

为了更直观，我们看一段简化的 OCI Image Manifest。

{
   
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
   
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:<config-digest>",
    "size": 1024
  },
  "layers": [
    {
   
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:<layer-digest>",
      "size": 4096
    }
  ]
}

其中几个字段非常重要。

schemaVersion

表示 Manifest 使用的结构版本。这里的 2 是当前常见的 Manifest Schema 版本。

mediaType

表示当前对象的内容类型。

Registry 会利用它判断自己正在处理什么对象。

config

引用镜像配置对象，其中包含环境变量、启动参数、架构等信息。

layers

引用镜像文件系统层。每一层通常是一个独立的内容对象。

digest

对象的内容哈希，通常使用 SHA256。

这也是为什么 Docker 镜像仓库能够通过内容摘要识别对象，以及复用已经存在的镜像层。

而我们看到的：

pushing layers done

本质上只覆盖了整个镜像发布过程中的一部分。

三、Image Manifest 和 Manifest List 是一回事吗？

不是。

这两个概念很容易混淆。

普通 Image Manifest 描述的是一个具体镜像，例如一个 linux/amd64 镜像。

而 Manifest List，或者 OCI Image Index，则可以引用多个 Manifest。

典型场景就是多架构镜像。

例如：

Image Index
│
├── linux/amd64
│   └── Image Manifest
│
├── linux/arm64
│   └── Image Manifest
│
└── 其他关联 Manifest

当我们运行：

docker pull example/demo-service:v1

Docker 可以根据目标运行环境选择适合的平台镜像。

比如 AMD64 服务器使用 AMD64 版本，ARM64 服务器选择 ARM64 版本。

但值得注意的是：

Image Index 不一定只包含不同 CPU 架构的运行镜像，还可能包含与镜像关联的构建证明等附加 Manifest。

这就引出了本次故障中的第二个核心概念：Attestation。

四、Attestation 是什么？为什么 Docker 会自动生成它？

Attestation 翻译过来可以理解为证明、声明或证明材料。

在现代软件供应链安全体系中，我们不仅关心一个镜像能不能运行，还关心：

这个镜像是谁构建的？

使用了什么工具？

构建过程是否可信？

镜像与源码之间是否存在可验证的关联？

Docker BuildKit 支持通过 Attestation 携带相关构建元数据。

其中比较常见的两类是：

类型	作用
Provenance	记录构建来源、构建过程等证明信息
SBOM	软件物料清单，描述软件组件及依赖

Provenance 侧重回答“镜像从哪里来、怎么构建”。

SBOM 侧重回答“镜像里包含哪些软件组件”。

两者并不是一回事。

Docker BuildKit 从 v0.11 开始默认添加最小化的 Provenance Attestation。

这意味着，即使 Dockerfile 完全没有变化，只要底层构建工具及其默认配置发生变化，最终推送的镜像结构也可能发生变化。

例如，以前构建结果可能只有：

Image
└── Image Manifest

而启用构建证明后，可能变成：

Image Index
│
├── Image Manifest
│   ├── Config
│   └── Layers
│
└── Attestation Manifest
    └── Provenance Data

这也是为什么我们在单平台构建时，有时仍然会看到 exporting manifest list。

它不一定代表我们构建了多个 CPU 架构的镜像。

五、核心错误解析：application/vnd.oci.empty.v1+json 到底是什么？

现在回到这次报错。

unknown manifest class for application/vnd.oci.empty.v1+json

我们可以将它拆成两个部分。

5.1 `unknown manifest class`

这一段表示 Registry 在处理某种 Manifest 相关结构时，遇到了它无法接受或识别的类型。

需要特别说明：

这不等同于用户名密码错误。

虽然日志中出现了 denied，但不能直接据此判断是 Docker 登录失败或者仓库没有 Push 权限。

Docker Registry 的错误处理涉及对象校验、内容类型支持、策略限制等多个环节。

在这次故障中，前面已经出现了认证完成及镜像层上传完成的记录，结合后面的 OCI Media Type 错误，更应该优先排查格式兼容性。

5.2 `application/vnd.oci.empty.v1+json`

这一段才是真正值得研究的地方。

先看几个常见 Media Type。

Media Type	含义
`application/vnd.oci.image.index.v1+json`	OCI Image Index
`application/vnd.oci.image.manifest.v1+json`	OCI Image Manifest
`application/vnd.oci.image.config.v1+json`	OCI 镜像配置
`application/vnd.oci.image.layer.v1.tar+gzip`	Gzip 压缩镜像层
`application/vnd.oci.empty.v1+json`	OCI 空 JSON 描述对象

最后这个类型，并不是镜像损坏了。

它是 OCI Artifact 可以使用的一种合法的空配置描述。

例如：

{
    
  "mediaType": "application/vnd.oci.empty.v1+json",
  "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
  "size": 2,
  "data": "e30="
}

为什么它的大小是 2？

因为它表示的内容就是：

{
    }

只有两个字节。

这意味着它并不存储普通容器镜像那样的运行配置，而是用作不需要实际镜像配置的 OCI Artifact 的空配置对象。

Docker 官方的 Attestation 文档中，就给出了使用这种空 Config Descriptor 的 OCI Artifact Manifest 示例。

5.3 为什么 Attestation 要使用空 Config？

原因在于 OCI Artifact 和普通运行镜像的用途不同。

普通镜像需要描述：

运行架构
环境变量
EntryPoint
Cmd
文件系统层

而 Provenance Attestation 的核心目的是存储构建证明数据。

它不需要具有一套真实可运行的容器配置。

因此，在 OCI Artifact 格式下，Attestation Manifest 可以使用空配置描述对象，同时通过 artifactType、subject、layers 等字段描述它的类型、关联对象及证明内容。

简化后的结构类似这样：

{
     
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "artifactType": "application/vnd.docker.attestation.manifest.v1+json",
  "config": {
     
    "mediaType": "application/vnd.oci.empty.v1+json",
    "size": 2,
    "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a"
  },
  "layers": [
    {
     
      "mediaType": "application/vnd.in-toto+json",
      "digest": "sha256:<attestation-data-digest>",
      "size": 2048
    }
  ],
  "subject": {
     
    "mediaType": "application/vnd.oci.image.manifest.v1+json",
    "digest": "sha256:<image-manifest-digest>",
    "size": 1024
  }
}

这段示意 JSON 中，最值得关注的是三个字段。

artifactType 表示这个对象是 Attestation Artifact。

config 使用了 OCI Empty Descriptor。

subject 则把证明材料与目标镜像 Manifest 关联起来。

这是一种更规范的制品关联方式。

但问题也随之出现：

如果 Registry 不支持这种 OCI Artifact 表达方式，镜像本身即使完全正常，附带的证明 Manifest 也可能导致推送失败。

六、为什么以前正常，现在突然出问题？

这是我认为整次故障里最值得关注的部分。

很多开发者遇到类似情况后，第一反应是：

“代码没有改，Dockerfile 没有改，昨天还可以发布，为什么今天就不行了？”

问题可能根本不在应用代码上。

关键是 Docker BuildKit 的版本及默认行为发生了变化。

根据 Docker 官方文档：

BuildKit v0.11 及后续版本默认生成 Provenance Attestation。
从 BuildKit v0.32.0 开始，启用 OCI Media Types 时，Attestation 默认以 OCI Artifact 形式保存。
新版 Buildx 还提供了 BUILDX_NO_DEFAULT_OCI_ARTIFACT 环境变量，用于关闭这一默认格式行为。

注意，这里涉及两个独立的变化。

第一阶段：开始默认生成 Provenance。

第二阶段：改变 Provenance 的默认封装格式。

这是完全不同的事情。

如果 CI 使用了自动更新的 Docker Buildx、BuildKit 或 GitHub Actions 构建环境，就可能在没有修改业务代码的情况下，产出与此前不同的 OCI 镜像结构。

我不能仅凭这次日志认定具体是哪一次更新触发了故障，但从错误类型来看，这是一个非常值得优先验证的方向。

它提醒我们，CI/CD 中需要关注的不只是代码和依赖版本，还包括构建工具链的版本。

七、解决方案：关闭 Provenance 是否就够了？

对于当前这个错误，最直接的处理方式就是关闭构建证明的生成。

方案一：使用 `--provenance=false`

例如原来的构建命令是：

docker buildx build \
  --platform linux/amd64 \
  -t registry.example.com/example/demo-service:v1 \
  --push .

修改为：

docker buildx build \
  --platform linux/amd64 \
  --provenance=false \
  --sbom=false \
  -t registry.example.com/example/demo-service:v1 \
  --push .

这里两个参数的含义是：

--provenance=false

关闭 Provenance Attestation 的生成。

--sbom=false

关闭 SBOM Attestation 的生成。

从这次日志判断，最关键的参数是 --provenance=false。

--sbom=false 则是进一步明确，不为这条构建链路添加 SBOM 证明信息。

阿里云官方在处理其他因 Provenance 引起的镜像兼容问题时，也提供了 --provenance=false 这种解决方式。

需要注意的是，关闭 Provenance 不会改变应用的业务代码，但会减少随镜像发布的软件供应链证明信息。

如果生产环境有合规、审计或构建来源追踪要求，应优先评估支持相关 OCI Artifact 格式的镜像仓库。

方案二：通过环境变量关闭默认 Attestation

对于不方便直接修改 Buildx 命令的场景，也可以使用：

export BUILDX_NO_DEFAULT_ATTESTATIONS=1

然后执行原有构建命令：

make docker-release

这会关闭 Buildx 默认添加的 Attestation。

但要注意，该环境变量针对的是默认 Attestation；如果构建命令显式指定了其他 Attestation，仍然需要检查对应配置。

方案三：保留 Provenance，但切换 OCI Artifact 封装

如果希望保留供应链证明信息，可以尝试兼容性更高的旧封装方式。

在支持该参数的 Buildx 版本中：

export BUILDX_NO_DEFAULT_OCI_ARTIFACT=1

然后重新构建并推送。

这个变量的作用并不是关闭 Provenance，而是改变默认的 Attestation 封装格式。

两者区别如下：

配置	生成 Provenance	默认 OCI Artifact 封装
默认配置	是	较新 BuildKit 中通常是
`--provenance=false`	否	不适用
`BUILDX_NO_DEFAULT_ATTESTATIONS=1`	关闭默认生成	不适用
`BUILDX_NO_DEFAULT_OCI_ARTIFACT=1`	是	否

这个方案需要与实际 Buildx、BuildKit 版本配合验证，也不保证所有旧 Registry 都能接受。

但如果你对软件供应链证明信息有要求，它比直接关闭 Provenance 更值得考虑。

方案四：GitHub Actions 中直接修改构建配置

如果使用的是 docker/build-push-action，配置可以写成：

- name: Build and push Docker image
  uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    platforms: linux/amd64
    tags: registry.example.com/example/demo-service:v1
    provenance: false
    sbom: false

对于通过 Makefile 封装构建命令的项目，则应该直接修改 Makefile 中实际调用 docker buildx build 的位置。

例如：

IMAGE := registry.example.com/example/demo-service
TAG ?= latest

.PHONY: docker-release

docker-release:
    docker buildx build \
        --platform linux/amd64 \
        --provenance=false \
        --sbom=false \
 -t $(IMAGE):$(TAG) \
        --push .

如此一来，本地执行：

make docker-release TAG=v1

和 GitHub Actions 通过 Makefile 调用构建时，都能保持一致行为。

相比只在 GitHub Actions 中设置某个临时变量，我个人更倾向于把关键构建参数显式写进构建脚本。

因为这更容易审查，也更方便未来追踪构建产物的变化。

八、如何验证问题是否真正解决？

工程排障不能只停留在“加了参数以后命令不报错”。

我们还需要验证最终镜像确实可以从仓库读取。

首先，查看 Docker Buildx 版本。

docker buildx version
docker version

如果使用容器化 BuildKit Builder，还应检查实际 Builder 节点版本。

docker buildx ls
docker buildx inspect --bootstrap

其次，重新构建并推送。

docker buildx build \
  --platform linux/amd64 \
  --provenance=false \
  --sbom=false \
  -t registry.example.com/example/demo-service:v1 \
  --push .

随后查看远程镜像结构：

docker buildx imagetools inspect \
  registry.example.com/example/demo-service:v1

如果需要进一步查看原始 Manifest：

docker buildx imagetools inspect \
  --raw \
  registry.example.com/example/demo-service:v1

在单平台构建且没有其他附加对象的情况下，最终结果通常会比包含 Attestation 的 Image Index 更简单。

但不能仅凭是否存在 Image Index 判断成功与否。

真正重要的是镜像仓库能否接受并正确返回目标 Manifest。

最后可以在目标部署环境执行：

docker pull registry.example.com/example/demo-service:v1

如果能够正常拉取，并且启动后通过应用健康检查，才说明发布链路已经恢复。

对于 CI/CD，我还建议增加一个独立的推送后校验步骤。

因为“构建命令执行完成”和“部署端能够成功拉取镜像”并不是同一件事。

九、这次故障暴露了什么工程问题？

我觉得这次排障最大的价值，不是学会了一个 --provenance=false 参数。

而是重新认识了现代 Docker 构建与发布体系。

以前我们可能认为：

Dockerfile
    ↓
Build
    ↓
Image
    ↓
Push
    ↓
Registry

只要应用构建成功，镜像就应该可以推送。

但现代容器镜像的构建与发布已经不是这么简单。

更准确的关系是：

Dockerfile + Build Context
           │
           ▼
        BuildKit
           │
           ├── Image Config
           │
           ├── Image Layers
           │
           ├── Image Manifest
           │
           └── Attestation
                  │
                  ├── Provenance
                  └── SBOM（按配置）
           │
           ▼
    OCI Manifest / Index
           │
           ▼
      Container Registry
           │
           ▼
      Runtime / Deployment

其中任何一个环节的格式支持范围发生变化，都可能影响最终发布结果。

这里面至少有三个经验值得总结。

第一，不要把推送失败直接等同于构建失败。

构建成功、镜像层上传成功、Manifest 校验成功，是不同的阶段。

必须根据最后一个失败步骤定位问题。

第二，CI/CD 的稳定性依赖整个构建工具链。

Docker、Buildx、BuildKit、GitHub Actions Runner 和 Registry 都属于构建发布链路的一部分。

如果对构建结果的可重复性要求较高，就应该记录并尽可能固定关键工具版本，同时有计划地升级。

第三，镜像仓库并不是简单的文件存储服务。

它需要理解和处理 OCI Distribution 协议、Manifest Media Type、Image Index，以及越来越多的供应链元数据。

因此，不能简单认为“一个仓库支持 Docker 镜像”就代表它支持所有 OCI Artifact 格式。

尤其在 Provenance、SBOM、镜像签名逐渐普及的背景下，镜像仓库的兼容性会越来越重要。

十、最后总结

回顾这次故障，整个问题其实可以浓缩成一条逻辑链：

Docker Buildx 构建镜像
        ↓
BuildKit 生成 Provenance
        ↓
Attestation 使用 OCI Artifact 格式
        ↓
Config 引用了 OCI Empty Descriptor
        ↓
Registry 无法接受对应格式
        ↓
unknown manifest class
        ↓
镜像推送失败

从日志特征、Docker 官方规范和工具行为来看，这是最符合当前证据的原因。

不过，要严格确认具体是哪一版 BuildKit 引发的变化，以及实际 ACR 实例对哪些 Media Type 有限制，还需要结合构建版本、远程 Manifest 和 Registry 能力进一步验证。

对于不依赖供应链证明信息的普通项目，可以先使用：

--provenance=false --sbom=false

解决当前推送问题。

而对于需要保留构建证明的生产系统，更合理的长期方案是检查 Registry 对 OCI Artifact 的支持情况，并统一构建工具链版本。

写到这里，我想再强调一句：

一次 Docker 镜像推送失败，可能和业务代码、Dockerfile 甚至网络权限都没有直接关系，而是底层镜像规范演进带来的兼容性问题。

这类问题最有价值的地方，恰恰是它会迫使我们去理解平时被工具隐藏起来的那一层原理。

我是王仕宇，JavaPub 的作者。

平时主要分享后端开发、Go、Docker、Kubernetes、云原生和 AI 工程实践。

希望这次真实故障的分析，能够帮到遇到同类问题的开发者。

参考资料

本文基于实际工程故障整理。日志中的项目、仓库、镜像版本及摘要均已脱敏，技术分析基于公开规范与工具文档。

在这里插入图片描述

Docker镜像推送与OCI证明结构解析-2.png

Docker 镜像明明构建成功，为什么推送到阿里云 ACR 却失败了？深入剖析 OCI Manifest 兼容问题

Docker 镜像明明构建成功，为什么推送到阿里云 ACR 却失败了？深入剖析 OCI Manifest 兼容问题

一、故障现场：为什么所有步骤都显示成功，最后却失败了？

1. `exporting manifest` 成功

2. `exporting attestation manifest` 成功

3. `pushing layers` 成功

4. `pushing manifest` 显示 done

5. `unknown manifest class` 是最终失败原因

二、要理解这个错误，先搞清楚 Docker 镜像到底是什么

三、Image Manifest 和 Manifest List 是一回事吗？

四、Attestation 是什么？为什么 Docker 会自动生成它？

五、核心错误解析：application/vnd.oci.empty.v1+json 到底是什么？

5.1 `unknown manifest class`

5.2 `application/vnd.oci.empty.v1+json`

5.3 为什么 Attestation 要使用空 Config？

六、为什么以前正常，现在突然出问题？

七、解决方案：关闭 Provenance 是否就够了？

方案一：使用 `--provenance=false`

方案二：通过环境变量关闭默认 Attestation

方案三：保留 Provenance，但切换 OCI Artifact 封装

方案四：GitHub Actions 中直接修改构建配置

八、如何验证问题是否真正解决？

九、这次故障暴露了什么工程问题？

十、最后总结

参考资料

热门文章

最新文章

相关电子书

探索云世界

热门

云计算

大数据

云原生

人工智能

数据库

开发与运维

活动广场

任务中心

训练营

直播

乘风者计划

下载

镜像站

技术资料

Docker 镜像明明构建成功，为什么推送到阿里云 ACR 却失败了？深入剖析 OCI Manifest 兼容问题

Docker 镜像明明构建成功，为什么推送到阿里云 ACR 却失败了？深入剖析 OCI Manifest 兼容问题

一、故障现场：为什么所有步骤都显示成功，最后却失败了？

1. exporting manifest 成功

2. exporting attestation manifest 成功

3. pushing layers 成功

4. pushing manifest 显示 done

5. unknown manifest class 是最终失败原因

二、要理解这个错误，先搞清楚 Docker 镜像到底是什么

三、Image Manifest 和 Manifest List 是一回事吗？

四、Attestation 是什么？为什么 Docker 会自动生成它？

五、核心错误解析：application/vnd.oci.empty.v1+json 到底是什么？

5.1 unknown manifest class

5.2 application/vnd.oci.empty.v1+json

5.3 为什么 Attestation 要使用空 Config？

六、为什么以前正常，现在突然出问题？

七、解决方案：关闭 Provenance 是否就够了？

方案一：使用 --provenance=false

方案二：通过环境变量关闭默认 Attestation

方案三：保留 Provenance，但切换 OCI Artifact 封装

方案四：GitHub Actions 中直接修改构建配置

八、如何验证问题是否真正解决？

九、这次故障暴露了什么工程问题？

十、最后总结

参考资料

热门文章

最新文章

相关电子书

1. `exporting manifest` 成功

2. `exporting attestation manifest` 成功

3. `pushing layers` 成功

4. `pushing manifest` 显示 done

5. `unknown manifest class` 是最终失败原因

5.1 `unknown manifest class`

5.2 `application/vnd.oci.empty.v1+json`

方案一：使用 `--provenance=false`