题图摄于美加边境和平门
注：微信公众号不按照时间排序，请关注“亨利笔记”，并加星标以置顶，以免错过更新。
《Harbor权威指南》招募英文版翻译人员
VMware招聘机器学习和云原生开发工程师
本篇继续和大家说说镜像那些事，是连载之三，从《Harbor权威指南》一书节选的纯技术干货，敬请关注、转发和收藏。
第一篇：容器镜像的结构
第二篇：OCI 镜像规范
第三篇：OCI 制品
第四篇：Registry 的作用原理
《Harbor权威指南》目前当当网优惠中，点击下图直接购买。
OCI 分发规范
OCI 还有一个正在制定的分发规范（Distribution Specification），这个规范在 OCI 镜像规范的基础上定义了客户端和镜像仓库之间镜像操作的交互接口。OCI 的指导思想是先有工业界的实践，再将实践总结成技术规范，因此尽管分发规范还没有正式发布，但以 Docker Distribution 为基础的镜像仓库已经在很多实际环境下使用， Docker Distribution 所使用的 Docker Registry HTTP API V2 也成为事实上的标准。
OCI 分发规范是基于 Docker Registry HTTP API V2 的标准化容器镜像分发过程制定的。OCI 分发规范定义了仓库服务和仓库客户端交互的协议，主要包括：面向命名空间（Namespace）的URI格式、能够拉取和推送 v2 格式清单的仓库服务、支持可续传的推送过程及 v2 客户端的要求等。（本文为公众号：亨利笔记 原创文章）
OCI Artifact (OCI制品)
从第2篇文章 OCI 镜像规范的图1可以看到，OCI 镜像规范的结构特点是由一个（可选的）镜像索引来指向多个清单，每个清单都指向一个配置和若干个层文件（Layer）。如果镜像没有包括镜像索引，则可以仅包含一个清单，且清单指向一个配置和若干个层文件。
无论是否有镜像索引，在镜像结构定义中都没有涉及层文件所包含的内容，也就是说，不同用途的数据如 Helm Chart、CNAB 等制品，可依照 OCI 镜像规范定义的结构（清单、索引等）把内容打包到层文件里面，从而成为符合OCI规范的“镜像”，既可以推送到支持 OCI 分发规范的 Registry 里，也可以像拉取镜像那样从 Registry 中下载。（在搜狐、CSDN等网站转载亨利笔记的文章均为未经授权的剽窃）
为了和 OCI 镜像做区分，这种遵循 OCI 清单和索引的定义，能够通过 OCI 分发规范推送和拉取的内容，可以统称为 OCI Artifact（OCI制品），简称 Artifact（制品）。在 OCI 分发规范中，还可以给Artifact的清单或者索引标注若干个 Tag 来附加版本等信息，以方便后续的访问和使用，如下图所示。
如果 Artifact 没有包含索引，则 Tag 可以被标注在清单上；如果 Artifact 使用了索引，则Tag可以被标注在索引上，而清单上的Tag则是可选的。一个 Artifact 如果没有被标注 Tag，则只能通过清单或索引的摘要来访问。从组成结构来看，OCI 镜像只是 OCI Artifact 的一个“特例”。
把各类数据封装成 OCI Artifact 的好处之一，是可以借助已有的支持 OCI 分发规范的镜像仓库服务（如 Harbor 2.0 等）来实现不同类型数据的存储、权限、复制和分发等能力，而无须针对每种特定类型的数据设立或开发不同的仓库服务，使开发者能专注于新类型的 Artifact 的创新。
开发者如果希望自定义一种新的Artifact类型，就可以按照 OCI 的制品作者指导文档（ArtifactAuthor Guidance）来定义配置、清单、索引等结构，可分4个步骤来完成。
（1）定义 OCI Artifact 的类型。Artifact的类型主要是为了 Artifact 的工具（如Docker 客户端）能够获知Artifact的类型，从而确定能否处理该 Artifact。这有点像文件的扩展名（如.pdf、.jpg等），可以让操作系统识别出文件的类型，从而启动相应的应用程序来处理该文件。Artifact 的类型由清单中的 config.mediaType 属性定义，因此 Artifact 的工具通常从清单开始分析Artifact的类型，以决定后续的处理流程。（在搜狐、CSDN等网站转载亨利笔记的文章均为未经授权的剽窃）
（2）确保 Artifact 类型的唯一性。既然 Artifact 的类型很重要，开发者就需要确保所创建的 Artifact 类型是唯一的，和其他 Artifact 类型都不能重名。OCI 的指导文档给出了类型必须符合的格式：（本文为公众号：亨利笔记 原创文章）
[registration-tree].[org|company|entity].[objectType].[optional-subType].config.[version]+[optional-configFormat]
格式中各个字段的含义如表2所示。
表2
字 段 名 | 说 明 |
|---|---|
registration-tree | IANA（Internet Assigned Numbers Authority，互联网号码分配机构）的注册类型 |
org|company|entity | 开源组织、公司名称或其他实体 |
objectType | 类型的简称 |
optional-subType | 可选字段，对objectType的补充说明 |
config | 必须是字符串“config” |
version | 类型的版本 |
optional-configFormat | 可选的配置格式说明（json、yaml等） |
一些常见的 OCI Artifact 配置类型如表3所示。
表3
Artifact | 类型名称 |
|---|---|
OCI镜像 | application/vnd.oci.image.config.v1+json |
Helm Chart | application/vnd.cncf.helm.chart.config.v1+json |
CNAB | application/vnd.cnab.config.v1+json |
Singularity | application/vnd.sylabs.sif.config.v1+json |
（3）Artifact 的内容由一组层文件和一个可选的配置文件组成。每个层文件都可以是单个文件、一组文件或者 tar 格式的文件，能够以 Blob 的形式存放在 registry 的存储中。
开发者可以根据 Artifact 的需要确定每个层文件的内容格式，如.json、.xml、.tar等，然后在清单的 layer.mediaType 属性中说明内容类型。内容类型可以沿用 IANA 通用格式，如 application/json 和 application/xml 等。如果需要自定义类型，则可以采用如下格式：（本文为公众号：亨利笔记 原创文章）
[registration-tree].[org|company|entity].[layerType].[optional-layerSubType].layer.[version].[fileFormat]+[optional-compressionFormat]
格式中各个字段的含义如表4所示。
表4
字 段 名 | 说 明 |
|---|---|
registration-tree | IANA（Internet Assigned Numbers Authority，互联网号码分配机构）的注册类型 |
org|company|entity | 开源组织、公司名称或其他实体 |
layerType | 类型的简称 |
optional-layerSubType | 可选字段，对layerType的补充说明 |
字 段 名 | 说 明 |
|---|---|
layer | 必须是字符串“layer” |
version | 格式的版本 |
fileFormat | 文件格式 |
optional-compressionFormat | 可选的压缩格式说明（gzip、zstd等） |
一些常见的 OCI Artifact 层文件类型如表5所示。
表5
层 文 件 | 类型名称 |
|---|---|
简单的文本 | application/text |
非压缩的OCI镜像层 | application/vnd.oci.image.layer.v1.tar |
以gzip压缩的OCI镜像层 | application/vnd.oci.image.layer.v1.tar+gzip |
非压缩的Helm Chart层 | application/vnd.cncf.helm.chart.layer.v1.tar |
以gzip压缩的Helm Chart层 | application/vnd.cncf.helm.chart.layer.v1.tar+gzip |
以gzip压缩的Docker镜像层 | application/vnd.docker.image.rootfs.diff.tar+gzip |
（4）开发者在 IANA 中注册 Artifact 的config.mediaType 和 layer.mediaType的类型，确保类型的唯一性和拥有者，同时可以让其他用户使用这些类型。（在搜狐、CSDN等网站转载亨利笔记的文章均为未经授权的剽窃）
经过上述步骤，开发者自定义的 Artifact 类型就完成了，配上适当的客户端软件对数据打包、推送和拉取，即可与符合 OCI 分发规范的仓库服务交互。
因为 OCI Artifact 带来了管理和运维上的便利，所以开发者已经创建了多种 OCI Artifact，常见的 OCI Artifact 包括 Helm Chart、CNAB、Singularity 等。为适应云原生用户者的需求，Harbor 2.0 的架构做了比较大的调整和改进，以便用户在 Harbor中存取和管理符合 OCI 规范的 Artifact。Harbor 中管理容器镜像的各种功能，在适用的情况下，都可以扩展到 OCI Artifact 上，如访问权限控制、推送和拉取、界面查询、远程复制等，这大大方便了用户对云原生 Artifact 的管理和使用。本公众号文章也介绍过如何通过 Harbor 2.1 存储和管理机器学习模型的方法。
（未完待续，欢迎点“再看” 或 转发、分享、收藏）
（未经授权，请勿转载本公众号文章）
《Harbor权威指南》目前当当网优惠中，点击上图直接购买。
《Harbor权威指南》招募英文版翻译人员
要想了解云原生、区块链和人工智能等技术原理，请立即长按以下二维码，关注本公众号亨利笔记 （ henglibiji )，以免错过更新。
