用 Image Builder 出镜像
This content is not available in your language yet.
想自己出镜像，第一件要确认的不是工具怎么用，而是官方已经提供了什么。本页先写清官方基线，再说明 Image Builder 与 compose 这部分证据本轮没有取得，最后给出一条不依赖具体工具的产出流程。
官方基线：Cloud 镜像由官方构建、维护并更新
Section titled “官方基线：Cloud 镜像由官方构建、维护并更新”官方下载页的「Cloud and container images」段落写明：官方构建、维护并更新 Cloud 镜像，并把这些镜像按对应版本支持的架构提供出来。
这条基线决定了自建镜像的定位：
- 官方镜像是对照组：自建产物与官方产物出现行为差异时，先查自己的构建输入；
- 官方只对它自己的产物负责：官方镜像的更新节奏，不等于你的自定义镜像的更新节奏；
- 版本对应：镜像面向哪个 Stream 版本，见版本与支持。
Image Builder 与 compose：本次核对未取得官方说明
Section titled “Image Builder 与 compose：本次核对未取得官方说明”Image Builder 与 compose 在 CentOS Stream 上的可用性、安装方式与用法（含蓝图定义），本次核对未取得官方说明。
因此本页在这一块只做负向声明：
- 不写工具安装步骤，也不写任何蓝图语法或字段；
- 不给命令示例，避免把社区说法当成官方步骤；
- 不比较构建方式的优劣，可比较的一手来源不足。
需要这两项时，正确做法是回查官方下载页与官方文档的当期内容，而不是从本站的通用流程里推断工具行为。
通用产出流程：定义、构建、校验、分发
Section titled “通用产出流程：定义、构建、校验、分发”不依赖具体工具的产出流程，工程上就是四步，每一步的产物都要能追溯：
- 定义：写清目标平台的产物形态、目标架构与版本基线，也就是「给谁用、装在哪」，再动手选工具；
- 构建：把构建输入（版本基线、包集合、配置文件）全部纳入版本控制，保证同一输入能重建同一产物；
- 校验：验证可安装性、可启动性与首批配置是否生效，并核对产物的摘要与签名；
- 分发：产物进入内部仓库或镜像服务时登记来源、架构、版本与构建时间，供后续追踪与回退。
校验清单：产物能不能交付
Section titled “校验清单：产物能不能交付”- 身份唯一：产物名称、版本基线、构建时间可以唯一定位一次构建；
- 完整性可核对：摘要与签名齐备，且校验方法写在交付说明里；
- 可启动：在与目标平台同构的环境里真正启动过一次，而不是只跑完构建；
- 可回归：有一套最小验收用例，重复构建后仍能跑通；
- 可替换：新旧产物的差异有清单，回退到旧产物的路径已经存在。
与官方镜像的分工
Section titled “与官方镜像的分工”- 开发与验证：以官方镜像为基线，减少「是不是我改坏了」的干扰；
- 需要定制时：自建产物的每一处差异都写进清单，便于官方基线更新后重新评估；
- 长期在线的负载：镜像更新策略要与运维基线的窗口安排一致；
- 云上实例：镜像与实例侧的取舍见CentOS Stream 云镜像；
- 容器侧：镜像思路在容器上的用法与边界见容器实践。
- CentOS Stream 云镜像 — 官方云镜像的可得性与更新检查
- CentOS Stream 运维基线 — 镜像更新要跟上的窗口
- CentOS Stream 容器实践 — 镜像思路在容器侧的用法
- CentOS Stream 版本与支持 — 版本基线怎么选
- CentOS Stream 自动化 — 把构建接进流水线
- 服务器基线实践 — 交付之后的最小基线
- 服务器安装指南 — 非镜像场景的安装路径
- 官方：CentOS Stream 下载页