我们很高兴地宣布Docker Hub现在允许大家分发任何类型的应用程序Artifact了!你现在可以将所有内容统一部署，告别多注册表带来的种种困扰。
在此之前，大家只能使用Docker Hub来存储和分发容器镜像——或者容器运行时所使用的Artifact。这大大限制了我们的平台功能，毕竟容器镜像分发只是应用程序交付的冰山一角。如今，现代应用程序交付往往涉及多种类型的Artifact：
Helm Chart
WebAssembly 模块
Docker Volumes
SBOM
OPA 捆绑包
……以及许多其他自定义Artifact
开发者会经常与客户分享这些Artifact，借此为各项目实现相应的价值。因此在OCI开发小组忙于发布新的OCI Artifact规范的同时，我们还需要分出精力将应用程序Artifact打包成OCI 镜像。
Docker Hub的本职工作是担任镜像注册表，但它同时也适合分发应用程序Artifact。正因为如此，我们才决定将软件Artifact(打包为OCI镜像的形式)的支持能力引入Docker Hub。
— 1 —
什么是开放容器倡议(OCI)?
早在2015年，我们就曾协助建立开放容器倡议(OCI)这一开放治理结构，为容器镜像格式、容器运行时和镜像分发制定出统一标准。
OCI当中包含一系列核心规范，负责实现以下治理功能：
如何打包文件系统包
如何启动容器化的跨平台应用程序
如何使远程客户端可以访问打包的内容
与三者对应，运行时规范负责确定OCI镜像和运行时如何交互;镜像规范概述了如何创建OCI镜像;最后，分发规范定义了如何使内容分发具有互操作性。
OCI的总体目标是提高透明度、运行时可预测性、软件兼容性和分发能力。此后，我们向OCI捐赠了自己的容器格式和runC(OCI兼容的运行时)，另外还将OCI兼容的分发项目捐赠给了CNCF。
— 2 —
我们为什么要添加OCI支持?
要想支持容器化应用程序构建，容器镜像是其中不可或缺的重要一环。各个项目会在运行当中累积下大量镜像，因此集中式云存储就在了高效管理资源的理想选项——开发人员不必依赖本地存储，也不用担心镜像资源能否随时访问。但与此同时，开发人员也希望能把各种Artifact存储在Docker Hub当中。
只要将Artifact存储在Docker Hub中，我们就能轻松实现“随处访问”，同时通过Docker Hub的标准共享功能改进协作。如此一来，用户能够更好地控制应用程序交付的关键部分，进一步契合 OCI提出的内容分发目标。
— 3 —
如何管理不同的 OCI Artifact?
我们建议使用专用工具来帮助管理非容器OCI Artifact，例如Helm CLI for Helm图表或用于任意内容类型的OCI Registry-as-Storage(ORAS)CLI。
让我们通过几个用例来展示Docker Hub中的OCI支持。
使用Helm图表
作为备受期待的重要功能，Helm图表支持现已正式加入Docker Hub!作为演示，我们在这里创建一个简单的Helm图表并将其推送至Docker Hub。此过程遵循Helm官方指南，该Helm图表将作为OCI镜像被存储在注册表中。
首先，我们将创建一个demo Helm图表：
$ helm create demo
这将生成大家非常熟悉，可供编辑的Helm图表样板文件：
demo├── Chart.yaml├── charts├── templates│ ├── NOTES.txt│ ├── _helpers.tpl│ ├── deployment.yaml│ ├── hpa.yaml│ ├── ingress.yaml│ ├── service.yaml│ ├── serviceaccount.yaml│ └── tests│ └── test-connection.yaml└── values.yaml 3 directories, 10 files
完成编辑后，我们需要将Helm图表打包为OCI镜像：
$ helm package demoSuccessfully packaged chart and saved it to: /Users/martine/tmp/demo-0.1.0.tgz
在推送Helm图表之前，别忘了登录Docker Hub。建议大家创建一个相应的个人访问令牌(PAT)。你可以通过环境变量导出PAT，然后登录，如下所示：
$ echo $REG_PAT | helm registry login registry-1.docker.io -u martine --password-stdin
1、推送你的Helm图表
现在，大家已经可以将Helm图表推送到Docker Hub!但首先，请确保你拥有Helm图表的目标命名空间的写入权限。在本示例中，让我们推送到docker命名空间：
$ helm push demo-0.1.0.tgz oci://registry-1.docker.io/docker Pushed: registry-1.docker.io/docker/demo:0.1.0Digest: sha256:1e960ad1693c234b66ec1f9ddce80986cbf7159d2bb1e9a6d2c2cd6e89925e54
2、查看Helm图表并使用过滤器
现在，如果你登录Docker Hub并导航到demo存储库详情，就能在存储库标签列表中找到你的Helm图表：
你可以通过单击标签导航到Helm图表页面。该页面提供各种实用的Helm CLI 命令：
存储库内容管理现在更容易。我们添加了一个下拉按钮，可以按内容类型快速过滤存储库列表，这大大提高了内容的可发现性。只需单击内容下拉菜单并从列表中选择Helm：
使用Volume
开发人员在整个Docker生态系统中使用Volume来共享任意应用程序数据，例如数据库文件。现在，大家可以使用我们新近推出的Volume备份和共享扩展来备份Volume，还可以使用相同的下拉菜单过滤选项以查找包含Volume的存储库。
如果我们不打算使用Volume Backup & Share扩展，而是想直接的将Volume推送到Docker Hub(例如通过命令行)，并且仍然让Docker Hub将其识别为Volume，又该怎么办?最简单的方法是利用ORAS项目。让我们看一个简单的用例，它展示了ORAS CLI记录的示例。
首先，我们将创建一个将被打包为Volume的简单文件：
$ echo "bar" > foo.txt
为了让Docker Hub识别这个Volume，我们必须在创建时为OCI镜像附加一个config文件，并将其标记为特定的媒体类型。该文件可以包含任意内容，所以让我们这样创建：
$ echo "{\"name\":\"foo\",\"value\":\"bar\"}" > config.json
完成此步骤后，现在就可以推送Volume了。
1、推送你的Volume
神奇的一幕出现了。要让Docker Hub成功将OCI镜像识别为Volume媒体类型，对应的标记是application/vnd.docker.volume.v1+tar.gz。大家可以将媒体类型添加至config文件，并使用以下命令(以及其结果输出)将其推送至Docker Hub：
$ oras push registry-1.docker.io/docker/demo:0.0.1 --config config.json:application/vnd.docker.volume.v1+tar.gz foo.txt:text/plain Uploading b5bb9d8014a0 foo.txtUploaded b5bb9d8014a0 foo.txtPushed registry-1.docker.io/docker/demo:0.0.1Digest: sha256:f36eddbab8459d0ad1436b7ca8af6bfc512ec74f45d8136b53c16db87562016e
我们现在在demo存储库中有两种类型的内容，具体如下所示：
如果你导航到内容页面，将会看到一些基本信息，这些信息将在后续迭代中相应扩展。大家可以借此了解Volume内容。
2、处理通用内容类型
如果你在使用ORAS CLI推送Volume时，并未使用application/vnd.docker.volume.v1+tar.gz媒体类型，那么Docker Hub会将该Artifact标记为通用，以将其与可识别的内容区分开来。
让我们推送相同的Volume，但这次使用application/vnd.random.volume.v1+tar.gz这一Docker Hub无法识别的媒体类型：
$ oras push registry-1.docker.io/docker/demo:0.1.1 --config config.json:application/vnd.random.volume.v1+tar.gz foo.txt:text/plain Exists 7d865e959b24 foo.txtPushed registry-1.docker.io/docker/demo:0.1.1Digest: sha256:d2fb2b176ee4e326f1f34ecdaede8db742f2c444cb2c9ceff0f5c8b743281c95
可以看到，新内容被分配了一个通用Other类型。我们仍然可以通过将鼠标悬停在类型标签上来查看标记内容的媒体类型。在本示例中，就是application/vnd.random.volume.v1+tar.gz：
如果大家想要筛选同时包含Helm图表和Volume的存储库，请使用右上角的同一下拉菜单：
使用容器镜像
最后，你可以继续将常规容器镜像推送到存放其他Artifact的同一存储库。假设我们重新标记Redis Docker官方镜像并将其推送到Docker Hub：
$ docker tag redis:3.2-alpine docker/demo:v1.2.2 $ docker push docker/demo:v1.2.2 The push refers to repository [docker.io/docker/demo]a1892d5d1a6d: Mounted from library/redise41876edb6d0: Mounted from library/redis7119119b7542: Mounted from library/redis169a281fff0f: Mounted from library/redis04c8ef03e935: Mounted from library/redisdf64d3292fd6: Mounted from library/redisv1.2.2: digest: sha256:359cfebb00bef01cda3bc1ca453e6455c770a246a06ad8df499a28118c144eda size: 1570
查看你的容器镜像
现在访问Docker Hub上的demo存储库页面，你将看到Tags and scans下列出的每个Artifact：
我们还将很快推出更多功能，帮助大家更好地组织应用程序内容，敬请期待更多公告!
— 4 —
关注更多更新
现在，每位开发者都可以在使用Docker Hub构建和分发应用程序时，访问和选择各种强大的Artifact。这不仅突破了既有局限，也将帮助大家创建和发布更令人兴奋的应用程序。
但我们的使命不止于此。我们一直在努力加强对OCI的支持。虽然OCI Artifact规范本身只是一个候选版本，但对OCI引用类型和随附Referrers API的全面支持即将登陆Docker Hub。欢迎大家继续关注即将推出的增强功能和repo组织设计。