作者：Doug Rabson
OCI 容器引擎，比如 containerd 和 podman，需要容器镜像。容器镜像是个只读目录树，通常包含一款应用程序及其支持文件和库。容器镜像在容器引擎上运行时，会创建该镜像的可写副本，并在某种隔离环境（如 jail）中执行该应用程序。通过注册中心分发容器镜像。注册中心存储镜像数据，提供了一个简单的 REST API 来访问镜像及其元数据。由开放容器标准对注册中心的 API、镜像格式和元数据进行标准化，基本上取代了早期的 Docker 格式。
镜像被表示为一系列层，每层都存储成 tar 压缩文件。为了解压镜像，我们从一个空目录开始，然后依次解压每层，后面的层可以增加文件及修改先前层中的文件。通常，这个过程的结果会被容器引擎缓存。
除了层数据，还额外使用了两个元数据对象。清单（manifest）列出了各个层，可包含描述镜的注解。镜像配置（image config）描述了目标操作系统和架构，并可使用默认命令来运行镜像。
所有这些都存储在一个“内容可寻址”的结构中，其中组件的哈希值用于为其命名。例如，我用于静态链接应用程序的小型基础镜像如下所示：
此捆绑包中的所有元数据文件都是 JSON 格式，如此处所描述。顶层的 index.json 文件通过其哈希链接到清单（manifest）：
该清单描述了两个数据层，一层仅包含 FreeBSD 标准目录结构，另一层包含最小的支持文件，如 /etc/passwd 和 SSL 证书。它还链接到了配置文件，其中包含目标操作系统和架构。
使用这样的内容可寻址格式，可以更容易地共享存储空间，并减少在使用多个基于相同基础镜像派生的镜像时，所需的下载数据量。
OCI 镜像规范还支持多架构镜像，它们只是清单的列表：
为了更方便地在 FreeBSD 上使用容器，需要合适的基本镜像。传统的 FreeBSD 发布流程生成的基本镜像，包含了一小部分用于在物理机和虚拟机上安装完整功能的 FreeBSD 操作系统的包。我们可以使用 base.txz 这个包来构建我们的基本镜像，但这会生成个大小为 1GB 的镜像，对于大多数应用程序来说，其中超过 90% 的内容是多余的。相比之下，大多数 Linux 发行版提供的基本镜像要小得多——比如，Ubuntu 官方镜像约为 80MB。
幸运的是，pkgbase 项目正在努力构建一个精细化的包集合，将传统的 base.txz 压缩包拆分成数百个更小的包。目前，这个集合包括许多单独的库和实用程序包，以及两个较大的包：FreeBSD-runtime 包含 shell 和一些核心实用程序，FreeBSD-utilities 包含一组常用的实用程序。
早先，我使用 pkgbase 创建了一个“最精简”镜像，包含 FreeBSD-runtime、SSL 证书和 pkg。这个镜像约为 80MB，足以支持简单的 shell 脚本，并且能够安装其他软件包。与类似的 Linux 镜像相比，这个镜像效果相当好，尽管它还无法与基于 busybox 的 alpine 镜像相媲美：后者的大小仅为 7.5MB。此后，我制作了一个小型的镜像家族，部分受 distroless 项目的启发：
“static”：仅包含 SSL 证书和时区数据。可以作为静态链接应用程序的基础。
“base”：在“static”基础上，增加了一些共享库，以支持大量的动态链接应用程序。
“minimal”：在“base”基础上，增加了 FreeBSD-runtime 包和包管理功能。
“small”：在“minimal”基础上，增加了 FreeBSD-utilities，能支持更多基于 shell 的应用程序。
为了支持多种 FreeBSD 版本，我将版本号嵌入镜像名称中，例如，“freebsd13.2-minimal:latest”包括来自最新版本的 releng/13.2 分支的包，而“freebsd13-minimal:latest”则是从 stable/13 构建的。我为 amd64 和 arm64 架构构建了所有这些镜像，容器引擎可自动从清单列表中选择正确的镜像。
容器镜像的安全性至关重要，必须能够验证其来源是否可信，并确保在传输到容器引擎的过程中未被篡改。
镜像的清单通常包含镜像数据层的 SHA256 哈希值以及对应的镜像配置文件的哈希值。这意味着可以通过清单的哈希值唯一标识镜像，并使用它来验证镜像，例如通过在可信的位置列出可信的镜像哈希。
另外，哈希值可以用于创建签名，证明该镜像得到了某个公钥持有者的信任。常用的两种机制是：Podman 使用的工具 sigstore，它使用 PGP 创建镜像签名，提供了将镜像集合与签名存储（可以是本地目录或可信网站）关联的机制。这可以用于在拉取镜像时，验证镜像是否与签名匹配。sigstore 的替代方案是 cosign，它将签名与镜像一起存储在镜像库中。
虽然这些镜像很有用，但它们包含的已安装软件包是根据相对无序的选择来决定的。最初，我维护了 alpha.pkgbase.live 软件仓库，这简化了通过安装额外包来扩展镜像的过程。不幸的是，该项目失去了资助，一段时间内，没有公开的 pkgbase 仓库可用。幸运的是，这个问题已经得到解决，现在可以从标准的 FreeBSD 软件仓库获取 pkgbase 包。
当前的镜像构建机制使用 pkg 安装 pkgbase 包到镜像层中。这种方式很方便，并且能够记录安装到镜像中的内容。不幸的是，pkg 的元数据存储在 sqlite 数据库中，它不支持可重现的构建。sqlite 数据库中包含了软件包安装的时间戳——虽然可以将其覆盖为一个合适的常量时间，但即便如此，sqlite 数据库仍然不是可重现的。更大的问题是可信度——我将这些镜像托管在自己的个人仓库中（docker.io 和 quay.io），但从潜在用户的角度来看，缺乏理由认同这些镜像是可信的。即便我使用来自 FreeBSD 包仓库的软件包构建镜像，可这些镜像未签名，也未得到 FreeBSD 项目的支持。
在我看来，这是 FreeBSD 容器引擎潜在用户面临的一个重大障碍，阻碍了这些项目从当前的“实验性”状态过渡到可以考虑用于生产的状态。这一点已通过与多个开源项目的讨论得到证实，这些项目正在构建和使用镜像，并希望支持 FreeBSD 这个平台。
在理想情况下，除了托管 pkgbase 包之外，FreeBSD 项目还应该构建 FreeBSD 容器镜像，可以托管一个镜像注册中心，或者将这些镜像发布到像 docker.io 这样的公共仓库。我计划原型化对发布构建基础设施的扩展，将容器镜像构建集成到现有的 pkgbase 框架中，这可能有助于推动这一进展。
Doug Rabson 是一位软件工程师，拥有三十余年的经验，涉及从 1980 年代的 8 位文字冒险游戏到 2020 年代的每秒 TB 级分布式长期聚合系统。自 1994 年以来，他始终是 FreeBSD 项目的成员和提交者，目前正在致力于改善 FreeBSD 对现代容器编排系统（如 Podman 和 Kubernetes）的支持。