RHEL 9 为开发和生产提供最新的容器技术

三年前，随着红帽企业 Linux 8 (RHEL 8) 的发布，我们推出了应用流，一套采用全新概念的容器工具。这些新型容器工具使 RHEL 用户能够查找、运行、构建和共享容器。如需了解 RHEL 从 Docker 迁移至 Podman 的原因，以及我们为此做出的努力，请参阅 RHEL 8 通过软件工艺工具启用容器。

在之前发布的红帽企业 Linux 8.5 容器工具有哪些新变化？一文中，我们介绍了升级至 RHEL 9 所需的许多基础特性和功能。

RHEL 9 发布后，我们继续提供基于 Pod Manager (podman)、Buildah、Skopeo、Udica、CRIU 和其他 Linux 实用程序的容器工具。RHEL 9 持续秉承以前的理念：提供我们认为适合这项工作的最佳工具，让容器用户更轻松地从 RHEL 8 升级到 RHEL 9。本文将深入探讨打包容器 RHEL 9 采用的最新技术和新增功能。

• RHEL 8.6 对比 RHEL 9.0 - 有何不同？

• 身份映射的集中管理

• 容器存储支持 NFS

• Podman 4.0 的高级网络堆栈

• 可移植证书和签名容器

• crun 成为 RHEL 9.0 中的默认容器运行时

• 控制组 v2 (cgroup 2) 成为 RHEL 9 和 Podman 中的默认值

RHEL 8.6 对比 RHEL 9.0 - 有何不同？

首先，让我们了解一下 RHEL 的背景信息。RHEL 8.6 和 RHEL 9.0 是我们所说的同步版本。两者几乎在同一时间发布，并将继续保持同步，直到 RHEL 8 更新到 8.10 版本并进入维护支持阶段，而 RHEL 9 将继续提供新功能。这样，用户可以在两个平台上获得大约两年的功能更新体验，并提供了升级窗口。RHEL 生命周期的设计宗旨是简化升级，这同样适用于容器工具。

注意下图中，RHEL 8 和 9 的以下版本是同步的：

• RHEL 9 Alpha -> RHEL 8.4

• RHEL 9 Beta -> RHEL 8.5

• RHEL 9.0 GA -> RHEL 8.6

• RHEL 9.1 -> RHEL 8.7

• RHEL 9.2 -> RHEL 8.8

• RHEL 9.3 -> RHEL 8.9

• RHEL 9.4 -> RHEL 8.10

RHEL 8 和 9 之间的此类同步简化了升级并扩展到 Podman、Buildah 和 Skopeo 版本。没错，Podman、Buildah 和 Skopeo 的快速稳定版本在版本之间保持一致。例如，RHEL 8 和 9 之间的 Podman 最新版本是相同的：

RHEL 8

cat /etc/redhat-release  红帽企业 Linux 8.6 (Ootpa) [root@lance ~]# podman --version podman 4.0.2

RHEL 9

cat /etc/redhat-release  红帽企业 Linux 9.0 版 (Plow) podman --version podman 4.0.2

在 RHEL 的主要版本之间同步 Podman 等重要软件可简化升级，但仍有一些您应注意的变化。在 RHEL 8.X 中，我们发布了两个应用流，一个允许开发人员访问最新版本的 Podman、Buildah 和 Skopeo，另一个是稳定的应用流，为运维团队提供为期两年的支持生命周期。

RHEL 8 应用流

RHEL 8 中所用的方法面临着一些挑战。首先，稳定流没有被大量采用，这打破了我们在启动 RHEL 8 时的最初假设。我们在 RHEL 8 中推出了快速稳定的流，并认为人们希望在访问稳定的容器 API (Podman) 的同时，仍然使用最新、最好的操作系统数据（Linux 内核、systemd 等）。这一直是基于容器的操作系统的需求。

事实证明，这种假设是错误的。相反，RHEL 用户主要寻求对稳定容器工具流的访问，以及对整个 RHEL 的两年延长更新支持 (EUS)。事实证明，基于 RHEL 构建的用户希望能够访问生命周期更长的整个操作系统。因此，我们改变了在 RHEL 9 中发布容器工具的方式。

RHEL 9 滚动应用流和 EUS

在 RHEL 9 中，我们还提供了两种使用容器工具的方式，一种专注于快速移动，另一种则侧重于稳定性。要访问最新、最出色的 Podman、Buildah 和 Skopeo 版本的开发人员和用户可以使用应用流 ，该产品最多每 12 周发布一次（与 RHEL 8 类似）。按照设计，这一应用流与 RHEL 8 上的快速流保持同步（直到推出 8.10 版本，此后 RHEL 8 会降低开发速度），从而可以轻松地在主要版本之间进行升级/降级。

如果 RHEL 9 用户需要在两年内访问具有安全性后移植的稳定流，则可以通过 RHEL 延长更新支持 (EUS) 来访问该流，不过这是单独的订阅服务。根据设计，RHEL 9 EUS 版本中的每个容器工具版本都与 RHEL 8 中对应的稳定流保持同步。如前所述，这使得从 RHEL 8 升级到 RHEL 9 变得更轻松，同时还保持了 Podman 版本的一致，以及减少引入出错的情况。

需要注意的是，RHEL 8 将继续按设计原样交付。而不会转换为 RHEL 9 使用的方法。如果您的开发人员、管理员或架构师已计划基于稳定流推出 RHEL 8，那您可以继续使用原来的工具，而无需 EUS。

还应当注意的是，在 RHEL 8.6 中， container-tools:2.0 模块已被弃用，您应该迁移至更新的版本（3.0、4.0 等），以继续获得安全补丁。有关更多信息，请参阅 RHEL 应用流生命周期页面。

身份映射的集中式管理

无根 Podman 是一项非常出色的技术。该技术以非根用户身份运行容器，并由此提高容器安全性，与在系统上运行常规进程类似。这意味着，攻击型工作负载需要突破额外的安全层，首先要通过容器控制，然后设法成为根。这非常适合大量笔记本电脑/台式机、HPC 环境，甚至是共享服务器上的开发人员。

但是，管理大量 RHEL 工作站、HPC 节点或共享服务器队列中的大量非根用户在以前非常困难，因为管理员需要管理在每个节点上手动创建的 /etc/subuid 和 /etc/sugid 文件。

但以后不用这样了。在 RHEL 9 里，我们在身份管理 (IdM) 中引入了一项功能，让管理员得以跨用户和 RHEL 节点队列轻松管理无根 podman 用户。用户可以将 subuids/subgids 分配给单个用户，也可以分配给目录服务器中的所有用户。真的非常方便。有关更多信息，请参阅第 29 章。手动管理 subID 范围。

支持用于容器存储的 NFS

如上所述，无根 Podman 是一项出色的功能，管理员通常在许多节点（工作站、HPC、共享开发人员服务器等）上拥有许多用户。在这些情形中，用户会希望随身携带数据。例如，如果用户在一个节点上执行“Podman 拉取”，他们希望该镜像在集群中的任何节点上都可用。对于普通进程，使用 NFS 便可轻松满足这一要求，但这向来便不适用于 Podman/容器。

借助这一新功能，Podman 现在可以将数据存储在任何支持扩展属性 (xattrs) 的 NFS 服务器上。非根/无根用户只需拉取镜像一次，便可在其主目录的任何适用位置使用。对于工作站、HPC 节点，甚至是完成 CI/CD 的共享开发服务器，此功能带来了非常大的便利。有关更多信息，请参见这篇上游文章： 使用无根 Podman 在 NFS 上运行容器的新功能

Podman 4.0 的高级网络堆栈

在带有 Podman 4.X 的 RHEL 9 版本中，用户可以使用新型网络堆栈。该版本提供了一些新功能，如更好的 IPv6 支持、对多个网络环境中容器的增强支持，以及改进的性能。

以下文章很好地为您概述了相关信息：Podman 4.0 的新网络堆栈：您需要了解的内容。

可移植证书和签名容器

随着 RHEL 8.4 的发布，我们推出了 UBI Micro，这是业界最小、最快的容器镜像之一（红帽 UBI Micro 简介）。

随着 RHEL 9 的发布，我们在此技术的基础上创建了一个微型 OpenSSL 容器镜像 (12.5MB)，可用于简单的加密用例，例如生成 SSL 证书请求、验证 SSL 证书，甚至签署文件。

这为开发人员提供了一种标准化的方式，让其无论是在生产环境中还是在台式机/笔记本电脑上，都可以执行受信任的加密用例。与所有红帽通用基础镜像一样，您和您的开发人员可以随时随地使用和分发这一新的可移植证书和签名容器。

如需了解更多信息，请查看红帽生态系统目录中的清单

• ubi9/openssl

• ubi8/openssl

crun 成为 RHEL 9.0 中的默认容器运行时

红帽贡献者于 2020 年推出了 crun，这是一个符合 OCI 的快速、低内存 容器运行时 。在 RHEL 9 中，我们将 crun 作为默认的容器运行时。crun 和 runc 都将在 RHEL 9 的整个生命周期内受到支持。

将 crun 作为默认值，为管理员简化了许多低级别配置任务，提高了性能和内存利用率，并解锁了各种出色的用例。有关更多信息，请参见：快速且低内存占用的容器运行时 — crun 简介

Control Group v2 (cgroup 2) 成为 RHEL 9 和 Podman 中的默认设置

cgroup 2 项目是一个 Linux 内核组件，可提供相应的机制来隔离、测量和控制服务器上进程集的资源分配。这为管理员和基础架构软件（如容器引擎和运行时）提供了一种强大的机制，可以限制任何给定进程所使用的资源，这对容器尤其有用。

但是 cgroup 2 在 RHEL 8 中是首次得到支持，所以用户需要在启用后并重新启动。在 RHEL 9 中，cgroup 2 是开箱即用的默认机制，可以对无根容器进行更精细的控制（抢先了解：Fedora 31 上的无根容器和 cgroup v2）。有关 cgroup 2 的详细介绍，请参阅： 借助 RHEL 8 的 cgroups 占据主导地位：欢迎使用 cgroups v2！

结语

RHEL 9.0 和 Podman 4.0.2 提供了许多出色的新容器功能，其中许多功能也在 RHEL 8.6 中提供。无论是想要体验最新、最出色的环境，还是想要充分利用现有安装，容器工具应用流的设计和架构都能满足您的需求。

在 RHEL 9 中，我们将继续提供对最新、最出色的 Podman、Buildah 和 Skopeo 的快速访问，但现在我们还支持您通过 EUS 访问稳定流。我们努力让客户更加方便地使用 RHEL 9 ，希望您能喜欢。我们很乐意听取您的反馈意见。

欢迎联系我们的新任容器工具产品经理 Mark Russell (https://www.linkedin.com/in/marrusl/) 、RHEL 服务器产品经理 Scott McCarty (@fatherlinux)、我们的技术营销经理 Eric Hendricks (@itguyeric)，或通过在我们的红帽企业 Linux 官方帐户 @rhel) 下发推文来向我们提供反馈。