Rocky Linux 上的容器运行时

在 Rocky 上跑容器，绕不开的问题不是「能不能跑」，而是运行时从哪来、镜像从哪来。这两件事官方都给了入口：运行时有 Podman 指南，镜像有官方镜像树里的一组容器镜像。本页只写这两条能核实的线索，其余放进通用实践。

官方给出的运行时路径：Podman 指南

官方文档在 Gemstones 的 Containers 组里提供 Podman 指南：它把 Podman 描述为 Docker 兼容的替代运行时，并说明 Podman 随 Rocky 仓库提供、可作为 systemd 服务运行，指南章节覆盖安装 Podman、运行容器，以及用 quadlet 与 podman generate systemd 两种方式把容器托管为 systemd 服务。

官方镜像树里的容器镜像系列

官方镜像树里另有一组容器镜像：Container 的 Base、Minimal、Toolbox、UBI 四个系列，每个系列同时提供带构建日期的 .oci.tar.xz 与 latest 形态的 .tar.xz，且每个文件旁都有同名 CHECKSUM 与 CHECKSUM.asc 签名。

把两条线索接起来看，路径是清楚的：

运行时：官方文档给出了 Podman 这条路径，包括把它托管为 systemd 服务的两种做法；
镜像来源：官方镜像树提供了带校验与签名的容器镜像文件，可以导入、可以核对；
不交叉推断：镜像树里有某个系列，不等于运行时的行为、标签策略或更新节奏随之确定。

运行时的通用取舍

以下做法与具体发行版无关，属于本站整理的工程实践，不是官方条款：

默认 rootless：以普通用户身份运行容器，权限面更小；确实需要更高权限的场景单独评估，而不是默认放开；
不要靠关闭安全机制排障：把强制访问控制或隔离机制关掉，往往会把一个问题变成两个问题；
固定摘要而不是标签：生产负载按内容摘要引用镜像，标签只作为人读别名；
镜像只从可信入口进：内部仓库只接纳已登记来源的镜像，人工导入留审批记录；
重建与扫描成对出现：镜像基线更新后重新扫描，扫描结果要能对应到具体摘要与重建批次。

镜像基线的更新检查

容器镜像是有保质期的资产，把它固定成常规检查项，比出事之后再查省事得多：

回查官方入口：确认镜像树的条目与版本是否已经更新；
分清两条线：镜像基线的更新与容器内软件包的更新是两件事，各自算窗口；
先小范围验证：新基线先在与生产同构的环境跑一遍冒烟用例，再扩大范围；
留可回退的旧摘要：新镜像验证通过前，旧摘要保留在可回退的位置；
记录基线：镜像取自哪个系列、什么时候取的、对应哪个摘要，应能在一处查到。

常见误解

「容器在 Rocky 上要另外找运行时」：官方文档已经给出 Podman 这条使用路径，从仓库安装到 systemd 托管都有对应章节；
「官方镜像树里只有系统盘镜像」：同一棵树里还有一组容器镜像系列，形态与用途和云镜像并不相同；
「有校验文件就不用管来源」：校验与签名解决的是完整性，来源是否可信是另一件事；
「基础镜像更新了，负载行为不变」：镜像换代可能带来行为差异，重建之后要跑同一套回归。