CentOS Stream 自动化

This content is not available in your language yet.

自动化的价值不在「少点几次鼠标」，而在每一次交付都可重复。CentOS Stream 的持续交付特性让这件事更重要：上游内容一直在动，如果你的环境靠人工步骤拼出来，很快就会出现「同一份配置装出两台不一样的机器」。

无人值守安装

本次核对未取得官方关于 Kickstart 无人值守安装的文档，因此本页不给示例、参数清单或无人值守配置文件的写法；这一条在证据台账中仍为待补。

在拿到官方原文之前，可以确定的是通用批量交付实践：

先固化一份最小安装基线：分区、账户、安全策略、时间同步、日志留存，先在一台机器上定稿，再作为所有环境的起点；
把人工步骤记成清单：清单里每一步都要能回答「谁做、什么时候做、做完怎么验证」，这本身就是后续自动化的输入；
区分「装机」与「配置」：装机负责把系统放到可登录状态，配置负责把它变成业务需要的形态；两段分开，替换其中一段时不必推翻另一段；
可重复优先于快：一次成功的批量部署不算成功，能在第二次、第十次得到同样结果才算。

镜像来源与批量同步

官方镜像页给出 CentOS Stream 的整体同步方式：用 rsync 从 CentOS-Stream-All 模块镜像全部内容，另有排除源码包与排除调试信息包的两种裁剪模块。

# 官方给出的整体同步写法（镜像全部内容）
rsync -aqzH --delay-updates --delete-after rsync.stream.centos.org::CentOS-Stream-All /path/to/local/mirror/root

# 排除源码包，占用更少的磁盘空间
rsync -aqzH --delay-updates --delete-after rsync.stream.centos.org::CentOS-Stream-nosrc /path/to/local/mirror/root

# 排除调试信息包，占用更少的磁盘空间
rsync -aqzH --delay-updates --delete-after rsync.stream.centos.org::CentOS-Stream-nodebug /path/to/local/mirror/root

把同步出来的内容当作批量环境的内容来源，有三个直接好处：

带宽收敛：成百台机器不再各自去公网取内容，而是取同一份内部副本；
交付可复现：同一批机器安装时看到的是同一份内容快照，出现问题也容易复现；
变更可控：同步是显式动作，你可以决定什么时候把新内容引入，而不是被动跟随上游。

CI 镜像与缓存

CI 环境最怕的不是慢，而是结果不稳定。把 CentOS Stream 用进 CI 时，按下面的顺序设计：

基础镜像先行：把「干净的系统」做成一份可复用的基础镜像或镜像层，所有流水线从它开始，而不是每条流水线各自装一遍；
缓存分层：基础层（很少变）、依赖层（偶尔变）、构建产物层（每次都变）分开缓存，避免一次依赖变化让全部缓存失效；
标签用不可变标识：浮动标签会让「昨天能过、今天不过」变成常态；用内容摘要固定版本，需要更新时显式改一次；
失败要能重放：保留足够的信息（镜像标识、内容来源、执行时间）让失败的构建可以原样重跑。

补丁策略

持续交付意味着没有「补丁日」这个概念：内容准备好就发布。你的策略因此不该是「有没有补丁」，而是「什么时候把变更引入自己的环境」：

分批推进：先一处验证，再小批，最后全量；批次之间留出观察时间；
变更窗口写死：上游随时在动，你的引入时间必须由自己控制，尤其是有状态服务；
回退路径先于更新路径：能重建镜像就重建，能回滚快照就回滚；没有回退手段时不要全量推进；
把业务验证挂上钩：更新之后跑的不是「系统起来了」，而是关键业务检查项。

一致性校验

批量环境最容易出现的问题是漂移：有人手工改了一台机器，几个月后你才发现它与其余机器不同。控制漂移靠的是定期比对，而不是靠纪律：

清单化：记录每台机器上装了哪些软件包、来自哪些来源，形成可比对的清单；
定期比对基线：与基线镜像或初始清单对比，差异要么被解释、要么被修正；
校验与签名纳入流程：内容来源要可验证，拿到的内容要能核对（见CentOS Stream 下载与校验）；
把校验结果留档：比对结果本身就是下一次变更决策的输入。