4. RHEL安装部署标准化与自动化交付

当企业需要交付几十台甚至上百台RHEL服务器时，逐台插入安装介质、手工分区、逐项勾选软件包的做法既慢又不可复现。标准化交付的核心思路是：把“安装过程中所有需要人工回答的问题”提前固化成一份可被安装程序读取的应答文件，再让机器通过网络自动获取这份文件并完成安装。RHEL生态中承担这一职责的三类工具分别是Kickstart、PXE与Image Builder，它们解决的是不同层面的问题，而不是互相替代的关系。

Kickstart：把安装过程写成一份可审计的应答文件

Kickstart文件本质上是一份纯文本的安装脚本，Anaconda安装程序在启动时读取它，按其中的指令完成语言、时区、磁盘分区、软件包选择、网络配置、root密码与用户创建、首次开机脚本等全部动作。它最大的价值不是“快”，而是“一致”——同一份ks文件装出来的机器，分区布局、软件集合、SELinux状态、防火墙策略完全相同，这为后续批量运维和验收提供了确定的基础。

一份可用于生产的ks文件通常包含几个关键段落。命令段负责全局设置，例如：

#version=RHEL9
text
lang zh_CN.UTF-8
keyboard --vckeymap=cn --xlayouts='cn'
timezone Asia/Shanghai --utc
rootpw --iscrypted $6$xxxxxxxxxxxx
selinux --enforcing
firewall --enabled --service=ssh
network --bootproto=dhcp --device=link --activate

分区段决定磁盘结构，生产环境建议显式声明而不是依赖自动分区，例如给/boot 1GiB、/ 50GiB、swap按内存大小取16GiB、剩余空间给/data，并指定xfs文件系统。软件包段用%packages声明最小化安装加必要工具，例如@^minimal-environment配合vim、chrony、firewalld、tuned。脚本段用%post完成安装后的收尾，比如注册到内部YUM源、下发监控agent、写入资产标签。需要特别注意的是，%post中的命令以chroot方式在目标系统执行，若需访问安装介质或网络资源，要显式挂载或使用--nochroot。

ks文件写完后必须做语法校验，否则安装到一半报错会浪费大量时间。RHEL提供了ksvalidator工具：

ksvalidator -v RHEL9 /var/www/html/ks/rhel9-base.ks

校验通过后再放入HTTP服务目录，供安装程序通过网络读取。这一步是标准化交付中成本最低、收益最高的质量门禁。

PXE：让裸机自己找到安装源和应答文件

Kickstart解决“装什么”，PXE解决“怎么启动到安装程序”。一台没有操作系统的裸机，网卡固件会先发DHCP请求，DHCP服务器除了分配IP，还要通过next-server和filename字段告诉它TFTP服务器地址和引导文件名。客户端从TFTP取回引导程序（BIOS用pxelinux.0，UEFI用shim.efi与grubx64.efi），引导程序再根据MAC地址或默认配置加载内核vmlinuz与initrd.img，并在内核命令行中追加inst.ks=http://.../rhel9-base.ks，安装程序启动后自动拉取应答文件，全程无需人工干预。

搭建PXE环境需要DHCP、TFTP、HTTP三个服务协同。DHCP配置中关键字段是：

subnet 192.168.10.0 netmask 255.255.255.0 {
  range 192.168.10.100 192.168.10.200;
  option routers 192.168.10.1;
  next-server 192.168.10.5;
  filename "pxelinux.0";
}

TFTP根目录下需要放置引导程序、内核、initrd以及pxelinux.cfg/default配置文件。HTTP服务则同时提供安装树（从ISO解压出的BaseOS与AppStream目录）和ks文件。三者缺一不可，排障时也应按这个顺序检查：客户端是否拿到IP、是否成功下载引导文件、内核是否加载、ks是否被正确读取。

Image Builder：从“装系统”升级为“交付镜像”

Kickstart与PXE解决的是“把系统装到物理机上”，而Image Builder（组件包为osbuild-composer）解决的是“把系统做成一个可分发、可版本化的镜像”。它通过composer-cli定义蓝图（blueprint），声明基础包、附加包、内核参数、用户与组，然后输出qcow2、AMI、VMDK、ISO、tar等多种格式。对于需要快速复制相同环境的场景，比如批量创建虚拟机模板、向云平台交付标准镜像，Image Builder比逐台PXE安装更高效。

一个典型的蓝图定义如下：

name = "rhel9-web-base"
description = "RHEL9 web server baseline"
version = "1.0.0"

[[packages]]
name = "httpd"
version = "*"

[[packages]]
name = "chrony"
version = "*"

[customizations.kernel]
append = "audit=1"

[[customizations.user]]
name = "deploy"
password = "$6$yyyyyyyy"
groups = ["wheel"]

推送蓝图后执行composer-cli compose start rhel9-web-base qcow2，构建完成后用composer-cli compose image <uuid>导出镜像。整个过程可重复、可版本化，蓝图文件本身就可以纳入Git管理，实现“镜像即代码”。

三种工具的定位与配合

标准化交付的验收要点

自动化安装做完不等于交付完成，验收要能回答三个问题：装出来的系统是否与基线一致、安装过程是否可重复、异常是否可定位。建议在ks的%post末尾写入一份安装指纹，例如记录安装时间、ks文件版本、软件包清单摘要到/etc/delivery-manifest，验收时直接比对多台机器的指纹即可判断一致性。同时保留Anaconda日志/var/log/anaconda/，其中anaconda.log记录流程、packaging.log记录包安装、ks.cfg记录实际生效的应答内容，出现偏差时可快速回溯是ks写错还是安装介质版本不符。

把Kickstart、PXE、Image Builder三者纳入同一套版本管理，配合ksvalidator校验与安装指纹比对，才能把“装机器”从个人经验变成可审计、可复现、可交接的标准化交付能力。