裸机自动装机：从 NetBox、BMC 到系统落盘
裸机装机不是一台 PXE Server 的魔法，而是一条由资产数据、带外管理、DHCP、启动文件和无人值守安装共同组成的状态机。
裸机自动装机经常被概括成一句话：“服务器从 PXE 启动，然后装好系统。”
真正落地时，一台机器要跨过资产登记、带外控制、网络引导、安装器和验收五个阶段。PXE 只是中间的一小段。任何一段的数据不一致，最后都会表现成“机器没装起来”。
与其把它当成一组脚本，不如把整条链路看成一台状态机。每一步都有明确输入、输出和可观测信号，失败后也应该能安全重试。
NetBox 先回答“这台机器应该是什么样”
自动化开始前，系统必须知道目标状态。
NetBox 这类 DCIM/IPAM 工具适合保存设备、机架位置、接口、MAC 地址、管理地址、业务地址、VLAN、硬件型号和角色。它更像基础设施的 source of truth，不应该被当成一个装机日志数据库。
一条装机任务至少要能从目标数据中得到：
- 设备的稳定身份，如资产编号、序列号和 BMC 地址；
- 用于网络启动的网卡及其 MAC 地址；
- 目标网络、IP、网关、DNS 和 VLAN；
- 固件启动模式，通常是 UEFI，也可能仍有 Legacy BIOS；
- 操作系统版本、磁盘布局和主机角色；
- 安装完成后要进入的配置管理、监控和资产状态。
MAC 地址很适合 DHCP 匹配，却不应成为唯一身份。换网卡、调整启动口或厂商返回不同格式，都可能让任务对错机器。比较稳妥的做法是用序列号或资产 ID 作为主键，再把 BMC、MAC 和目标 IP 当成关联属性。
自动化控制器读取 NetBox 后，应先做一致性检查：IP 是否冲突、BMC 是否可达、目标 MAC 是否唯一、硬件配置是否满足 OS 模板。数据没过关时，不要直接给机器上电。
BMC 负责在操作系统之外控制机器
服务器还没有操作系统，SSH 和配置管理工具都用不上。此时能控制它的是 BMC，也就是服务器上的带外管理控制器。
传统环境常用 IPMI，较新的设备通常也提供 DMTF Redfish API。Redfish 把电源、硬件清单、启动项等能力放进标准化的 HTTPS 资源模型中，比解析不同厂商的命令行输出更适合自动化。
控制器在这一阶段通常做三件事：
- 检查电源和硬件状态；
- 把下一次启动临时改为
Pxe，并选择正确的 UEFI/Legacy 模式； - 执行开机或重启。
DMTF 的 Redfish Schema 定义了 BootSourceOverrideTarget、BootSourceOverrideEnabled 和 BootSourceOverrideMode。其中 Once 表示只覆盖下一次启动，成功后回到正常启动顺序。装机系统优先使用一次性覆盖，比永久把 PXE 放在第一启动项更安全。否则装完系统重启时，机器可能再次进入安装流程。
BMC 网络应与业务网络隔离，凭证放在密钥系统中，并限制控制器只能操作任务对应的资产。能远程开关机和挂载介质的账号，本质上拥有接近物理接触服务器的权限。
DHCP 告诉固件“你是谁，第一段程序在哪里”
机器从网卡启动后，固件先取得网络参数和启动程序位置。
传统 PXE 流程中，客户端广播 DHCP 请求。DHCP 或 ProxyDHCP 根据 MAC、客户端架构等信息，返回地址、网关、启动服务器和 boot filename。随后固件通常通过 TFTP 下载第一段 Network Bootstrap Program。
这里最常见的问题是 BIOS 和 UEFI 混用。它们需要的启动程序格式不同，x86_64 UEFI、ARM64 UEFI 也不能共用同一个二进制。DHCP 配置应根据客户端架构选择对应 bootloader，不能只按网段返回一个固定文件。
TFTP 设计简单，适合固件阶段下载较小的 bootloader，但不适合承担整个系统镜像的传输。常见做法是：
固件 PXE
-> TFTP 下载 iPXE/GRUB
-> bootloader 通过 HTTP/HTTPS 读取脚本
-> HTTP/HTTPS 下载 kernel、initrd 和安装配置支持 UEFI HTTP Boot 的设备还可以直接通过 HTTP 获取 UEFI 启动程序，省掉 TFTP 这一跳。是否采用它，要看服务器固件的一致性与兼容性，不必为了“链路更新”强行替换已经稳定的 PXE。
iPXE 或 GRUB 把机器带进安装环境
bootloader 运行后，工作重点从“拿到第一段程序”变成“启动哪个内核，用什么参数启动”。
以 Linux 为例，iPXE 或 GRUB 通常下载安装内核和 initramfs，并在 kernel command line 中传入安装源、无人值守配置地址和必要的网络参数。RHEL 系列可以通过 inst.ks= 指向 Kickstart；Ubuntu 常用 Subiquity autoinstall 与 cloud-init 数据源。具体语法随发行版变化，链路结构相似。
无人值守配置负责真正的落盘动作，例如：
- 选择目标磁盘并创建 GPT/分区/LVM；
- 建立文件系统和挂载点；
- 安装基础包与内核；
- 配置用户、SSH key、网络和时区；
- 安装 bootloader；
- 执行必要的安装后脚本。
不要把长期有效的密码、token 或私钥直接放进内核命令行。它可能出现在 DHCP、Web 服务、控制台、进程参数和安装日志中。更安全的做法是使用短期、单机绑定的下载凭证，或让安装环境在完成可信身份校验后再取敏感配置。
启动文件和安装配置也要考虑完整性。能够篡改 DHCP 响应、TFTP 文件或安装脚本的人，等于能给整批服务器植入自己的系统。管理网络隔离、HTTPS、受控镜像仓库、签名校验与 Secure Boot 应按威胁模型逐步补齐。
装完系统不等于任务完成
安装器把系统写入磁盘、安装 bootloader 后，会重启并从本地盘进入新系统。此时自动化还差最后一段：验收与交接。
新主机应主动回调控制器，或由控制器等待一组可验证的信号，例如：
- 本地盘启动成功；
- 主机名和网络地址符合目标数据；
- SSH host key 或机器身份已经登记；
- 配置管理 Agent 完成首次收敛；
- 监控、日志和时间同步正常；
- 磁盘、网卡、内存与资产记录相符。
如果团队的状态模型里设置了 provisioning，也应等验收通过后再切到 active；具体状态名按实际工作流定义。单纯看到 ICMP 通，不足以证明系统装对了。
失败也要分阶段记录。BMC 不可达、DHCP 没回应、TFTP 找不到文件、HTTP 下载失败、内核启动失败、安装器磁盘报错、首次本地盘启动失败，应该对应不同状态和重试策略。把所有失败都记成 install_failed，后面很难自动修复。
一条装机链路应该怎样被观察
排障时可以沿着状态机逐跳确认：
资产校验
-> BMC 一次性 PXE 启动
-> DHCP 租约与架构识别
-> bootloader 下载
-> kernel/initrd 下载
-> 无人值守配置获取
-> 磁盘安装
-> 本地盘启动
-> 配置收敛与验收每一跳都要留下任务 ID、设备身份、开始时间、结束时间、结果和关键错误。HTTP 下载日志可以按任务关联，DHCP 租约可以反查 MAC，BMC 事件日志可以确认是否真的按 PXE 启动。这样一来，“装机失败”就能缩小到一个具体接口，而不是靠工程师盯着远程控制台猜。
成熟的裸机装机平台，核心不在某个神奇组件。它把 NetBox 中的目标状态、BMC 的物理控制、PXE 的启动发现、HTTP 的文件分发和安装器的磁盘操作接成一条可以审计、可以重试、也能随时停止的链路。