CentOS Stream 容器实践

容器这一块，本页能核实的官方事实比想象中少：能确认的只有「官方确实提供 Stream 的容器镜像」；至于基础镜像从哪里拉、用哪个运行时跑，本轮核对没有取得官方说明。因此本页把「官方事实」与「本站实践建议」分开写。

官方给了什么：Containers 入口

CentOS Stream 10 与 Stream 9 的官方下载表都给出了 Containers 入口，同一页还有专门的「Cloud and container images」段落。

这条事实的边界要说清楚，否则很容易被读成更多结论：

• 它只说明官方有容器镜像这条交付线，不说明镜像的名称、标签策略或获取地址；
• 它不说明运行时：下载页不回答「用哪个容器工具跑」，本页因此不做运行时对比；
• 它是活页面上的结论：入口与段落可能调整，重查方法见下载与校验。

Note

本页只复述已核实的条目。凡标注「本次核对未取得官方说明」之处，指的是本站没有拿到一手来源，不是「官方没有这回事」——两者不能互相替代。

基础镜像来源：本次核对未取得官方说明

基础镜像的具体获取位置、命名与标签策略，本次核对未取得官方说明。因此这一节不写任何地址或镜像名，只给可迁移的核对方法：

• 来源可追：能追到项目官方入口的镜像，才谈得上后续的更新与签名核对；
• 核对标识与摘要：把镜像标识、摘要与获取时间记进清单，而不是只记一个会变的标签；
• 不用来源不明的镜像名：无法解释它被谁、在什么时候重建过；
• 入库留痕：镜像进入内部仓库时保留来源信息，出事时才追得回去。

Caution

「本次核对未取得官方说明」是证据状态的描述，不是「官方不支持容器」的结论。要拿它做选型依据时，请以官方下载页与官方文档的当期内容为准。

运行时选择：本次核对未取得官方说明

用哪个运行时（引擎）来跑容器，同样本次核对未取得官方说明。能确定的是：运行时的选择会直接影响权限模型与运维方式，所以这一步值得当成设计决策，而不是随手一装：

• 先定责任边界：谁负责运行时升级、谁负责镜像重建，写进同一份文档；
• 按团队能力选：已有的排障经验，比「参数更像某个熟悉的命令」更重要；
• 不混用多套引擎跑同一批负载，否则排障前先要花时间确认自己在哪条链上；
• 隔离优先于便利：需要更强隔离时，先看平台既有能力，再考虑引入新组件。

rootless 与来源核对：通用实践

下面几条是通用工程实践，不依赖具体发行版与工具：

• 优先 rootless：容器以普通用户身份运行，权限面更小；需要 root 的场景单独评估，而不是默认放开；
• 别靠关掉安全机制排障：把强制访问控制或隔离机制关掉，会把一个问题变成两个问题；
• 固定的是摘要，不是标签：生产负载按摘要引用镜像，标签只作为人读的别名；
• 镜像只从可信入口进：内部仓库只允许来自已登记来源的镜像，人工导入要留审批记录；
• 扫描结果要能定位：漏洞报告要能对应到具体摘要与重建批次，否则无法判断是否已修复。

Note

这些做法与具体发行版无关，因此在官方说明缺失的情况下仍然可以执行；但它们不能替代官方对镜像与运行时的说明。

更新策略：把重建当成常态动作

Stream 的更新是持续向前走的，容器侧的对策不是「等一个稳定版」，而是把重建当成常规动作：

• 定期重建：按固定节奏用新的基础镜像重建并重新扫描，而不是等出事再动；
• 重建要能回归：重建后跑同一套冒烟用例，避免「镜像更新了、行为也变了」；
• 保留可回退的旧摘要：新镜像先小流量验证，旧摘要留到确认之后；
• 窗口对齐：更新节奏与运维窗口的关系见运维基线与仓库与滚动内容。

相关页

• 用 Podman 跑容器（主站参考 ↗） — 共享教程里的运行时操作基础
• CentOS Stream 云镜像 — 云与实例侧的镜像话题
• 用 Image Builder 出镜像 — 自己产出镜像时的边界与流程
• CentOS Stream 仓库与滚动内容 — 包从哪来、滚动意味着什么
• CentOS Stream 运维基线 — 更新窗口与最小运维规范
• CentOS Stream 版本与支持 — 支持窗口与版本状态
• 官方：CentOS Stream 下载页