CentOS Stream 容器实践
容器这一块，本页能核实的官方事实比想象中少：能确认的只有「官方确实提供 Stream 的容器镜像」；至于基础镜像从哪里拉、用哪个运行时跑，本轮核对没有取得官方说明。因此本页把「官方事实」与「本站实践建议」分开写。
官方给了什么：Containers 入口
Section titled “官方给了什么：Containers 入口”CentOS Stream 10 与 Stream 9 的官方下载表都给出了 Containers 入口，同一页还有专门的「Cloud and container images」段落。
这条事实的边界要说清楚，否则很容易被读成更多结论：
- 它只说明官方有容器镜像这条交付线，不说明镜像的名称、标签策略或获取地址；
- 它不说明运行时：下载页不回答「用哪个容器工具跑」，本页因此不做运行时对比；
- 它是活页面上的结论：入口与段落可能调整，重查方法见下载与校验。
基础镜像来源：本次核对未取得官方说明
Section titled “基础镜像来源：本次核对未取得官方说明”基础镜像的具体获取位置、命名与标签策略，本次核对未取得官方说明。因此这一节不写任何地址或镜像名，只给可迁移的核对方法：
- 来源可追：能追到项目官方入口的镜像，才谈得上后续的更新与签名核对；
- 核对标识与摘要：把镜像标识、摘要与获取时间记进清单，而不是只记一个会变的标签；
- 不用来源不明的镜像名：无法解释它被谁、在什么时候重建过；
- 入库留痕：镜像进入内部仓库时保留来源信息，出事时才追得回去。
运行时选择：本次核对未取得官方说明
Section titled “运行时选择：本次核对未取得官方说明”用哪个运行时（引擎）来跑容器，同样本次核对未取得官方说明。能确定的是：运行时的选择会直接影响权限模型与运维方式，所以这一步值得当成设计决策，而不是随手一装：
- 先定责任边界：谁负责运行时升级、谁负责镜像重建，写进同一份文档；
- 按团队能力选：已有的排障经验，比「参数更像某个熟悉的命令」更重要；
- 不混用多套引擎跑同一批负载，否则排障前先要花时间确认自己在哪条链上；
- 隔离优先于便利：需要更强隔离时，先看平台既有能力，再考虑引入新组件。
rootless 与来源核对：通用实践
Section titled “rootless 与来源核对：通用实践”下面几条是通用工程实践，不依赖具体发行版与工具：
- 优先 rootless：容器以普通用户身份运行，权限面更小；需要 root 的场景单独评估，而不是默认放开；
- 别靠关掉安全机制排障：把强制访问控制或隔离机制关掉，会把一个问题变成两个问题；
- 固定的是摘要，不是标签：生产负载按摘要引用镜像，标签只作为人读的别名；
- 镜像只从可信入口进：内部仓库只允许来自已登记来源的镜像，人工导入要留审批记录；
- 扫描结果要能定位：漏洞报告要能对应到具体摘要与重建批次，否则无法判断是否已修复。
更新策略：把重建当成常态动作
Section titled “更新策略：把重建当成常态动作”Stream 的更新是持续向前走的，容器侧的对策不是「等一个稳定版」，而是把重建当成常规动作：
- 定期重建：按固定节奏用新的基础镜像重建并重新扫描，而不是等出事再动；
- 重建要能回归：重建后跑同一套冒烟用例，避免「镜像更新了、行为也变了」；
- 保留可回退的旧摘要：新镜像先小流量验证，旧摘要留到确认之后；
- 窗口对齐：更新节奏与运维窗口的关系见运维基线与仓库与滚动内容。
- 用 Podman 跑容器（主站参考 ↗） — 共享教程里的运行时操作基础
- CentOS Stream 云镜像 — 云与实例侧的镜像话题
- 用 Image Builder 出镜像 — 自己产出镜像时的边界与流程
- CentOS Stream 仓库与滚动内容 — 包从哪来、滚动意味着什么
- CentOS Stream 运维基线 — 更新窗口与最小运维规范
- CentOS Stream 版本与支持 — 支持窗口与版本状态
- 官方：CentOS Stream 下载页