用 Image Builder 出镜像

想自己出镜像，第一件要确认的不是工具怎么用，而是官方已经提供了什么。本页先写清官方基线，再说明 Image Builder 与 compose 这部分证据本轮没有取得，最后给出一条不依赖具体工具的产出流程。

官方基线：Cloud 镜像由官方构建、维护并更新

官方下载页的「Cloud and container images」段落写明：官方构建、维护并更新 Cloud 镜像，并把这些镜像按对应版本支持的架构提供出来。

这条基线决定了自建镜像的定位：

• 官方镜像是对照组：自建产物与官方产物出现行为差异时，先查自己的构建输入；
• 官方只对它自己的产物负责：官方镜像的更新节奏，不等于你的自定义镜像的更新节奏；
• 版本对应：镜像面向哪个 Stream 版本，见版本与支持。

注意

「官方构建、维护并更新」是官方原文的表述。本站不据此推断镜像内部的技术细节——预装内容、初始化方式、默认配置都需要各自的官方来源。

Image Builder 与 compose：本次核对未取得官方说明

Image Builder 与 compose 在 CentOS Stream 上的可用性、安装方式与用法（含蓝图定义），本次核对未取得官方说明。

因此本页在这一块只做负向声明：

• 不写工具安装步骤，也不写任何蓝图语法或字段；
• 不给命令示例，避免把社区说法当成官方步骤；
• 不比较构建方式的优劣，可比较的一手来源不足。

需要这两项时，正确做法是回查官方下载页与官方文档的当期内容，而不是从本站的通用流程里推断工具行为。

通用产出流程：定义、构建、校验、分发

不依赖具体工具的产出流程，工程上就是四步，每一步的产物都要能追溯：

1. 定义：写清目标平台的产物形态、目标架构与版本基线，也就是「给谁用、装在哪」，再动手选工具；
2. 构建：把构建输入（版本基线、包集合、配置文件）全部纳入版本控制，保证同一输入能重建同一产物；
3. 校验：验证可安装性、可启动性与首批配置是否生效，并核对产物的摘要与签名；
4. 分发：产物进入内部仓库或镜像服务时登记来源、架构、版本与构建时间，供后续追踪与回退。

注意

这四步是通用工程实践的整理，不是对任何发行版工具的用法说明。工具怎么装、蓝图怎么写，属于上一节的未取得项。

校验清单：产物能不能交付

• 身份唯一：产物名称、版本基线、构建时间可以唯一定位一次构建；
• 完整性可核对：摘要与签名齐备，且校验方法写在交付说明里；
• 可启动：在与目标平台同构的环境里真正启动过一次，而不是只跑完构建；
• 可回归：有一套最小验收用例，重复构建后仍能跑通；
• 可替换：新旧产物的差异有清单，回退到旧产物的路径已经存在。

与官方镜像的分工

• 开发与验证：以官方镜像为基线，减少「是不是我改坏了」的干扰；
• 需要定制时：自建产物的每一处差异都写进清单，便于官方基线更新后重新评估；
• 长期在线的负载：镜像更新策略要与运维基线的窗口安排一致；
• 云上实例：镜像与实例侧的取舍见CentOS Stream 云镜像；
• 容器侧：镜像思路在容器上的用法与边界见容器实践。

相关页

• CentOS Stream 云镜像 — 官方云镜像的可得性与更新检查
• CentOS Stream 运维基线 — 镜像更新要跟上的窗口
• CentOS Stream 容器实践 — 镜像思路在容器侧的用法
• CentOS Stream 版本与支持 — 版本基线怎么选
• CentOS Stream 自动化 — 把构建接进流水线
• 服务器基线实践 — 交付之后的最小基线
• 服务器安装指南 — 非镜像场景的安装路径
• 官方：CentOS Stream 下载页