一、引言

在当今的云计算与容器化技术领域，OCI（Open Container Initiative）镜像标准扮演着极为关键的角色。它为容器镜像的构建、分发和运行提供了统一且规范的准则，促进了容器技术生态系统的繁荣与发展。无论是大规模的企业级容器集群部署，还是个人开发者的小型应用容器化实践，OCI 镜像标准都无处不在。本教程将深入探讨 OCI 镜像的各个方面，包括其标准格式、相关工具的使用以及与其他类似镜像格式（如 Docker 镜像、OSI 操作系统镜像）的对比等内容，旨在为读者提供全面、深入且实用的 OCI 镜像知识体系。

二、OCI 镜像标准格式详解

（一）镜像清单（Manifest）

镜像清单是 OCI 镜像的核心描述文件，采用 JSON 格式编写。它犹如一份蓝图，全面地涵盖了关于镜像的关键信息，其中最为重要的当属镜像层的摘要（digest）、镜像的架构（architecture）以及镜像的配置信息（config）等。以下是一个典型的 OCI 镜像清单示例：

在上述示例中：

• “schemaVersion”字段明确指定了清单的版本号。当前，版本 2 是较为常用的版本，不同的版本在功能和规范细节上可能会有所差异。随着 OCI 标准的不断演进，新版本的清单可能会引入新的特性或对现有特性进行优化，以适应不断变化的容器技术需求。
• “mediaType”字段则表明了清单文件自身的媒体类型。这一信息对于容器运行时和相关工具来说至关重要，它能够帮助它们准确地识别该文件所遵循的规范，从而采取相应的处理方式。例如，当一个工具接收到一个镜像清单文件时，通过读取“mediaType”字段，它可以确定该文件是一个 OCI 镜像清单，并依据 OCI 标准对其进行解析和处理。
• “config”部分是镜像配置信息的引用。它包含了镜像运行时所需的各种详细信息，如容器运行时所需的环境变量、入口点（entrypoint）、命令（command）等。其中，“digest”字段指向具体的配置文件内容（同样以 JSON 格式存储），而“size”字段则表示配置文件的大小。通过这种方式，镜像清单将镜像的配置信息与其他部分紧密关联起来，确保了整个镜像的完整性和一致性。
• “layers”数组是镜像清单的另一个关键组成部分，它详细列出了构成镜像的各个层。每个层都有自己的“mediaType”（通常是压缩的 tar 包格式，如上述示例中的“application/vnd.oci.image.layer.v1.tar+gzip”）、“digest”（层内容的哈希值，这是一个唯一标识该层的重要信息，通过对层内容进行哈希计算得到）和“size”（层的大小）。这些层按照特定的顺序堆叠起来，便形成了完整的容器镜像内容。一般来说，底层的层通常包含基础操作系统相关的文件和目录，而随着层次的递增，上层的层则逐步添加应用程序及其依赖项。这种分层结构的设计是 OCI 镜像的一大特色，它带来了诸多优势，例如在镜像的分发和存储过程中，可以实现层的复用，从而大大减少了镜像的存储空间和网络传输量。

（二）镜像配置（Config）

镜像配置文件同样采用 JSON 格式，它是镜像运行时的详细信息宝库，容器启动时，容器运行时会读取并依据这些信息来创建和启动容器。以下是一个镜像配置文件的示例：

在这个示例中：

• “created”字段精确地记录了镜像的创建时间，这对于镜像的版本管理和追溯非常有帮助。开发人员和运维人员可以通过这个时间信息，了解镜像的创建历史，确定不同版本镜像之间的先后顺序，以及在出现问题时能够快速定位到特定时间创建的镜像版本。
• “author”字段则明确标识了镜像的创建者。在一个团队协作或者开源项目中，这一信息有助于确定镜像的来源和责任人，方便进行沟通和协作。例如，如果在使用某个镜像时发现了问题，可以根据“author”信息联系到创建者，寻求解决方案或者反馈问题。
• “architecture”和“os”字段共同指定了镜像所适用的硬件架构和操作系统类型。这一点非常重要，因为不同的硬件架构（如 amd64、arm64 等）和操作系统（如 Linux、Windows 等）对于应用程序的运行有着不同的要求和支持。通过明确这两个字段，容器运行时可以确保在合适的环境中运行镜像，避免因架构或操作系统不匹配而导致的运行错误。
• “config”中的“Env”数组用于设置容器内的环境变量。这些环境变量可以影响应用程序在容器内的运行行为，例如设置应用程序的配置路径、数据库连接字符串等。在上述示例中，“PATH”环境变量指定了容器内的可执行文件搜索路径，而“APP_VERSION”则可以作为应用程序内部版本控制的一个标识。“Entrypoint”字段定义了容器启动时执行的入口程序，它是容器启动后首先运行的命令或脚本。而“Cmd”字段则可以作为入口程序的参数，如果在启动容器时有额外指定命令，则会覆盖这里的“Cmd”。例如，如果“Entrypoint”设置为“/bin/myapp”，而“Cmd”设置为“start”，那么容器启动时将执行“/bin/myapp start”。如果在启动容器时手动指定了其他命令，如“/bin/myapp stop”，则会优先执行手动指定的命令。
• “rootfs”部分描述了镜像的根文件系统。其中，“type”字段通常为“layers”，表示该根文件系统是由多个层组成的，这与镜像清单中的“layers”信息相互呼应。“diff_ids”字段则是各层内容的哈希标识，它与镜像清单中的层哈希相关联，用于构建根文件系统的分层结构。通过这些哈希标识，容器运行时可以准确地将各个层叠加起来，形成完整的根文件系统。

（三）镜像层（Image Layers）

镜像层是容器镜像的实际数据存储单元，是 OCI 镜像的重要组成部分。每个镜像层都是一个文件系统的增量，它包含了与前一层相比发生变化的文件和目录。这种分层结构的设计理念是 OCI 镜像的核心优势之一。例如，在构建一个基于 Ubuntu 操作系统的容器镜像时，首先会有一个包含 Ubuntu 基础系统文件的层，这个层可能包含了操作系统的内核、基本的系统库、文件系统结构等内容。当需要在这个基础上安装 Python 软件包时，会生成一个新的层，该层仅包含与 Python 安装相关的文件和配置，如 Python 的可执行文件、库文件、相关的配置文件等，而不会重复包含底层已经存在的 Ubuntu 基础系统文件。

镜像层通常以压缩的 tar 包（如 tar+gzip 格式）形式存储，其内容涵盖了文件、目录以及它们的元数据。在构建镜像的过程中，每次对文件系统的修改（如安装软件包、添加配置文件、更新文件内容等）都会生成一个新的层。这种分层结构带来了显著的好处，主要体现在镜像的复用方面。例如，假设有多个基于相同基础操作系统（如 Ubuntu）的容器镜像，它们都需要安装相同版本的 Python 软件包。由于 OCI 镜像的分层结构，这些镜像可以共享包含 Python 软件包的层，而无需在每个镜像中都重复存储该层的内容。这样一来，在存储方面，可以大大减少镜像所占用的存储空间；在网络传输方面，当从镜像仓库拉取这些镜像时，也只需传输一次共享的层，从而减少了网络流量的消耗，提高了镜像分发的效率。

当从镜像仓库拉取镜像时，容器运行时会根据镜像清单中的层信息，依次下载各个层。下载完成后，按照顺序将这些层解压并叠加在一起，最终构建出完整的容器根文件系统。在这个过程中，通过各层的哈希值（digest）来确保层的完整性和准确性，任何对层内容的篡改都会导致哈希值的改变，从而能够及时发现并防止恶意修改。

（四）媒体类型（Media Types）

OCI 镜像标准中定义了多种媒体类型，这些媒体类型在整个镜像的构建、分发和运行过程中发挥着重要的作用，它们用于准确标识镜像相关文件的格式和用途。不同的组件（如容器运行时、镜像仓库、构建工具等）通过识别这些媒体类型，能够正确地处理镜像相关的文件，从而确保整个容器生态系统的兼容性和互操作性。

• 对于镜像清单，常见的媒体类型如“application/vnd.oci.image.manifest.v1+json”，其中“v1”表示版本号，“json”表示文件格式为 JSON。这一媒体类型明确告知相关工具，该文件是一个遵循 OCI 标准的镜像清单文件，并且是版本 1 的 JSON 格式，工具在接收到这样的文件时，就会按照 OCI 镜像清单的解析规范来处理它。
• 镜像配置文件的媒体类型为“application/vnd.oci.image.config.v1+json”，同样通过“v1”和“json”的标识，让工具能够识别这是一个 OCI 镜像的配置文件，并且按照相应的格式和规范进行读取和处理。
• 镜像层的媒体类型例如“application/vnd.oci.image.layer.v1.tar+gzip”，表示这是一个压缩的 tar 包格式的镜像层文件，工具在处理该文件时，就会知道需要先解压该 tar 包，然后将其内容按照镜像层的要求进行处理，如叠加到根文件系统等操作。

通过这种明确且统一的媒体类型定义，无论是不同的容器运行时（如 Docker、Podman 等），还是各种镜像仓库（如 Docker Hub、Quay.io 等）以及构建工具（如 Buildah 等），都能够在处理 OCI 镜像相关文件时达成共识，确保整个容器技术生态系统的顺畅运行。

（五）内容寻址存储（Content Addressable Storage）

OCI 镜像采用内容寻址存储机制，这是一种基于内容哈希值（digest）的存储和标识方式。在这种机制下，镜像的每一部分（包括镜像清单、配置文件、镜像层等）都是通过其内容的哈希值来进行唯一标识的。例如，对于一个镜像层，无论它存储在何处，只要其内容没有发生改变，其哈希值就始终保持一致。这种方式带来了诸多显著的优点：

• 数据完整性验证：由于镜像内容与哈希值之间存在一一对应的关系，任何对镜像内容的非法篡改都会导致哈希值的改变。因此，在镜像的传输和存储过程中，可以通过计算和比对哈希值来轻松检测镜像是否被恶意修改。例如，当从镜像仓库拉取一个镜像层时，容器运行时可以在下载完成后重新计算该层的哈希值，并与镜像清单中记录的哈希值进行比对。如果两者一致，则说明镜像层在传输过程中没有被篡改，数据完整性得到了保证；反之，如果哈希值不匹配，则说明镜像层可能遭受了恶意攻击或者传输过程中出现了错误，此时容器运行时可以采取相应的措施，如拒绝使用该镜像层或者重新下载等。
• 缓存和复用：基于哈希值的标识使得相同内容的镜像部分可以在不同的镜像之间实现共享和复用。镜像仓库可以根据哈希值对镜像层进行缓存，当多个镜像包含相同的层时，只需要在仓库中存储一份该层的内容即可。例如，假设有多个基于相同基础操作系统的容器镜像，它们在构建过程中都使用了相同的一些基础软件包层。由于这些层的哈希值相同，镜像仓库只需存储一份这些基础软件包层的内容，而不同的镜像只需引用该层的哈希值即可。这样一来，不仅大大减少了镜像仓库的存储空间占用，还提高了镜像分发的效率。当用户拉取这些镜像时，对于已经缓存的相同层，无需再次下载，从而加快了镜像的拉取速度。

（六）镜像签名（Image Signing）

为了进一步增强镜像的安全性和可信度，OCI 镜像标准支持镜像签名机制。镜像签名允许镜像的创建者使用数字签名技术对镜像进行签名，从而证明镜像的来源和完整性。具体来说，签名过程通常涉及使用私钥对镜像的清单或其他关键信息进行加密签名，生成签名数据。然后将签名数据与镜像一起存储或分发。在使用镜像时，接收方可以使用对应的公钥来验证签名，从而确定镜像是否来自可信的源并且在传输过程中没有被篡改。

例如，在一个企业内部的容器化应用部署场景中，企业可以为自己的镜像创建私钥和公钥对。镜像创建者在构建和发布镜像时，使用私钥对镜像清单进行签名。当企业内部的其他团队或环境需要使用这些镜像时，他们可以使用预先分发的公钥来验证镜像的签名。如果签名验证成功，则说明镜像来自企业内部可信的源，并且在传输过程中没有被修改，可以放心使用；反之，如果签名验证失败，则说明镜像可能存在安全风险，不应被使用。通过这种镜像签名机制，企业可以有效地防止恶意镜像被部署到生产环境中，保障容器化应用的安全性和稳定性。

三、OCI 镜像相关工具介绍

（一）Buildah

• 功能特性：Buildah 是一款功能强大且灵活的用于构建 OCI 镜像的命令行工具。与传统的一些构建工具不同，Buildah 具有独特的优势，它不依赖于 Docker 守护进程，这使得它能够在那些没有 Docker 运行的环境中依然可以顺利地构建镜像。例如，在一些对资源占用和安全性要求较高的生产环境中，可能不希望或不能运行 Docker 守护进程，此时 Buildah 就成为了构建 OCI 镜像的理想选择。它提供了丰富的命令和选项，允许开发人员从基础镜像开始，逐步构建出完整的容器镜像。例如，可以使用 Buildah 创建一个空的容器文件系统，然后在其中安装所需的软件包、添加配置文件、设置环境变量等，最后将这个容器文件系统打包成一个 OCI 镜像。在构建过程中，Buildah 支持分层构建，能够精准地控制每一层的内容，从而有助于减小镜像的体积。例如，在安装多个软件包时，可以将每个软件包的安装过程分别放在不同的层中，这样当其中一个软件包需要更新时，只需要更新对应的层，而无需重新构建整个镜像。
• 使用示例：以下是一个简单的 Buildah 构建镜像的示例。首先，使用“buildah from”命令创建一个基于 Alpine Linux 的基础容器：

这将创建一个名为“alpine-working-container”的容器，接下来进入该容器的文件系统环境：

在容器内，可以使用 apk 命令安装所需的软件包，例如安装 nginx：

安装完成后，设置容器的一些配置信息，如环境变量、入口点等：

最后，将这个容器打包成一个 OCI 镜像：

这样就成功地使用 Buildah 构建了一个包含 nginx 的 OCI 镜像。

（二）Skopeo

• 功能特性：Skopeo 主要专注于处理 OCI 镜像的拷贝、签名验证以及在不同镜像仓库之间的传输等操作。它的一个显著特点是可以直接与各种支持 OCI 的镜像仓库进行交互，而无需将镜像先拉取到本地再进行推送。这一特性极大地提高了镜像传输的效率，减少了本地存储的需求。例如，如果需要将一个镜像从一个企业内部的私有仓库复制到一个公共的镜像仓库中，Skopeo 可以直接在两个仓库之间建立连接，并完成镜像的复制操作，而无需在本地机器上临时存储该镜像。同时，Skopeo 还支持对镜像签名的验证，能够确保镜像的来源可靠和内容完整。在涉及到安全性要求较高的镜像分发场景中，这一功能尤为重要。- 使用示例：假设要将一个位于私有镜像仓库“private-registry.example.com”中的镜像“my-image:latest”复制到公共镜像仓库“public-registry.example.com”，可以使用以下 Skopeo 命令：

如果要验证一个镜像的签名，可以使用“skopeo verify”命令，例如：

这将使用镜像中附带的签名信息和预先配置的公钥来验证镜像的完整性和来源。

（三）Podman

• 功能特性：Podman 是一个完全兼容 OCI 标准的容器运行时工具。它具有诸多优秀的特性，首先，Podman 不需要运行守护进程，这与传统的 Docker 运行方式有所不同。这种无守护进程的设计大大增强了系统的安全性，减少了因守护进程可能带来的安全风险，如权限滥用、漏洞攻击等。同时，Podman 直接与 OCI 镜像配合使用，能够高效地创建、运行和管理容器。例如，在部署一个微服务架构的应用时，Podman 可以根据 OCI 镜像快速启动多个容器实例，并且可以方便地对这些容器进行网络配置、资源限制、状态监控等操作。Podman 还支持容器的分组管理，通过创建容器组（Pod），可以将相关的容器组织在一起，实现统一的资源分配和网络管理，这与 Kubernetes 中的 Pod 概念类似，方便了在复杂应用场景下的容器编排。
• 使用示例：以下是一些 Podman 的基本使用示例。首先，使用“podman pull”命令从镜像仓库拉取一个 OCI 镜像：

拉取完成后，可以使用“podman run”命令启动一个容器：

这将在后台启动一个名为“my-nginx-container”的 nginx 容器。如果要查看正在运行的容器，可以使用“podman ps”命令：

要停止一个容器，可以使用“podman stop”命令：

（四）Crane

• 功能特性：Crane 是一个专门用于操作 OCI 镜像和容器的实用工具。它提供了一系列简洁而高效的命令，用于对镜像进行各种常见的操作。例如，它可以方便地查看镜像的标签信息，通过这些标签信息，用户可以了解镜像的版本、来源、构建时间等重要信息，有助于在镜像管理和应用部署过程中进行版本控制和溯源。Crane 还能够提取镜像中的文件，这在需要查看镜像内部特定文件的内容或者将镜像中的某些文件提取到本地进行分析或使用时非常有用。此外，Crane 可以删除不再需要的镜像，帮助用户清理镜像存储空间，保持镜像仓库的整洁和有序。
• 使用示例：要查看一个 OCI 镜像的标签信息，可以使用“crane manifest”命令，例如：

这将显示该 ubuntu 镜像的清单信息，其中包含了标签等相关内容。如果要提取镜像中的某个文件，比如提取一个配置文件，可以使用“crane export”命令：

这将把 nginx 镜像中的“/etc/nginx/nginx.conf”文件提取到当前目录下。要删除一个镜像，可以使用“crane rmi”命令：

四、OCI 镜像与其他镜像格式对比

（一）OCI 镜像与 Docker 镜像

• 镜像清单格式：
• OCI 镜像：严格遵循 OCI 标准的 JSON 格式清单，“schemaVersion”清晰地指定版本号，并且对清单中的各个字段（如镜像层、配置信息等）都有明确且规范的定义。这种标准化的格式使得不同的工具和运行时只要遵循 OCI 标准，就能够准确地解析和处理镜像清单。例如，在一个多容器运行时的环境中，如果使用了遵循 OCI 标准的工具链，那么对于 OCI 镜像清单的处理将是一致且可靠的。
• Docker 镜像：其镜像清单格式相对而言较为自由，在早期并没有严格统一到像 OCI 这样标准化的格式中。虽然在功能上与 OCI 镜像清单有相似之处，都用于描述镜像的相关信息，但由于缺乏严格的标准规范，在与其他非 Docker 原生的工具和运行时进行交互时，可能会因为格式差异而出现兼容性问题。例如，一些新兴的容器编排工具可能在处理 Docker 镜像清单时需要进行额外的格式转换或适配工作，这增加了系统的复杂性和潜在的出错风险。
• 镜像配置格式：
• OCI 镜像：以标准的 JSON 格式存储运行时详细信息，涵盖了创建时间、作者、架构、环境变量、入口点等丰富且规范的信息。这些信息的标准化使得不同的容器运行时能够准确地读取和执行相应的配置，从而确保了容器的一致性运行。例如，无论使用哪种支持 OCI 标准的容器运行时，对于相同的 OCI 镜像配置文件，都能够按照预期设置容器的运行环境和启动参数。
• Docker 镜像：其配置信息在格式和内容上与 OCI 镜像相似，但在细节上可能存在一些差异。由于 Docker 有自己独立且庞大的生态体系，在与其他非 Docker 原生的工具或运行时配合时，配置信息的转换可能会遇到困难。例如，当尝试将一个 Docker 镜像迁移到一个基于 OCI 标准但非 Docker 原生的容器平台时，可能需要对镜像的配置信息进行调整和转换，以确保其能够在新的平台上正确运行。
• 镜像层格式：
• OCI 镜像：层作为文件系统增量，以压缩的 tar 包（如 tar+gzip 格式）存储，其分层结构严格遵循标准规范。这种标准化的分层结构使得镜像层的复用性和存储优化达到了较高的水平。例如，在一个企业内部的容器镜像仓库中，如果存在多个基于相同基础操作系统的应用镜像，它们可以共享底层的操作系统层，从而大大减少了仓库的存储压力和网络传输量。
• Docker 镜像：同样采用分层结构，但在层的具体实现和管理上与 OCI 略有不同。Docker 镜像层的构建和存储方式在一定程度上依赖于 Docker 的内部机制，这可能导致在与其他容器技术共享镜像层时存在障碍。例如，当尝试将 Docker 镜像层与一个遵循 OCI 标准的容器构建工具进行集成时，可能会因为层格式和管理方式的差异而无法直接复用，需要进行额外的处理或转换。
• 媒体类型定义：
• OCI 镜像：明确定义了多种媒体类型，无论是镜像清单、配置文件还是镜像层，都有各自严格且清晰的媒体类型定义。这使得不同的组件（如容器运行时、镜像仓库、构建工具等）在处理镜像相关文件时，能够根据媒体类型准确地识别文件的格式和用途，从而确保整个容器生态系统的兼容性和互操作性。例如，一个容器运行时在接收到一个镜像文件时，可以通过媒体类型判断它是镜像清单、配置文件还是镜像层，然后按照相应的规范进行处理。
• Docker 镜像：在媒体类型定义上没有像 OCI 镜像那样高度标准化。这可能导致在与其他工具或运行时交互时，无法迅速且准确地识别镜像相关文件的格式和用途。例如，在一个混合容器技术的环境中，一些非 Docker 原生的工具可能在处理 Docker 镜像文件时，由于媒体类型不明确，难以确定文件的具体性质和处理方式，从而影响了整个系统的协同工作效率。

（二）OCI 镜像与 OSI 操作系统镜像

• 目的和用途：
• OCI 镜像：专门为容器化应用而设计，其核心目的是实现轻量级、快速部署以及高可移植性的应用运行环境。它聚焦于将应用程序及其依赖项打包成一个独立的、可在不同容器平台上运行的镜像单元。例如，一个简单的 Python Web 应用可以被打包成一个 OCI 镜像，这个镜像只包含了运行该应用所需的 Python 运行时环境、应用代码以及相关的依赖库，它可以在任何支持 OCI 标准的容器平台上快速启动和运行，无需考虑底层操作系统的差异（只要底层操作系统满足容器运行的基本要求）。
• OSI 操作系统镜像：主要用于安装完整的操作系统，其涵盖的内容极为广泛，包含了大量的系统级组件和工具，是构建物理机或虚拟机操作系统环境的基础。例如，在安装 Windows 或 Linux 操作系统到计算机上时，需要使用相应的操作系统镜像。这些镜像包含了操作系统的内核、各种驱动程序、系统服务、用户界面等完整的组件集，其目的是为了创建一个完整的、可供用户进行各种系统级操作和应用程序安装的操作系统环境。
• 结构复杂度：
• OCI 镜像：结构相对较为简单，主要由镜像清单、配置文件和镜像层这三个核心部分组成。其重点在于如何有效地组织和打包应用程序及其依赖项，以实现容器化应用的高效运行。例如，一个 Node.js 应用的 OCI 镜像可能只包含 Node.js 运行时和应用代码相关的几个层，以及对应的清单和配置文件，整体结构简洁明了，易于管理和维护。
• OSI 操作系统镜像：结构则复杂得多，它包含了完整的操作系统内核、大量的驱动程序（如显卡驱动、网卡驱动等）、各种各样的系统服务（如网络服务、文件服务等）以及完整的用户界面（如桌面环境、命令行界面等）等众多组件。以 Windows 操作系统镜像为例，其文件数量庞大，包含了从底层硬件驱动到上层应用程序接口的所有内容，这种复杂性是为了满足操作系统在各种硬件设备上的安装和运行需求，以及为用户提供丰富多样的功能和服务。
• 可定制性和灵活性：
• OCI 镜像：具有高度的可定制性，开发者可以根据应用的具体需求，精确地选择和打包所需的依赖项，从而构建出小巧高效的镜像。例如，对于一个只需要特定版本的 Python 运行环境和几个特定库的应用，开发者可以创建一个只包含这些内容的 OCI 镜像，避免了不必要的组件冗余，提高了镜像的运行效率和部署速度。并且，由于 OCI 镜像的分层结构和标准化格式，使得在镜像的定制过程中可以方便地进行层的添加、修改和删除操作。
• OSI 操作系统镜像：定制相对困难，通常需要专业的工具和技术来进行修改和定制。因为操作系统镜像包含了大量的系统级组件，这些组件之间相互关联、相互依赖，对其中一个组件的修改可能会影响到整个操作系统的稳定性和兼容性。例如，在定制一个 Windows 操作系统镜像时，如果想要修改内核参数或者删除某个系统服务，需要非常谨慎地操作，并且需要对操作系统的内部结构和运行机制有深入的了解，否则很容易导致操作系统无法正常启动或运行异常。

五、总结