在我管理香港机房的过程中，明明配置写得没问题，Ansible剧本也跑通了，但自动化部署频繁在裸金属初始化阶段卡壳。要么IPMI接口失联，要么BMC配置缺失，甚至有时候厂商预装固件版本不一致导致行为漂移。这让我意识到，如果不在部署前就统一BMC配置，后续的自动化就不具备可重复性。
于是，我决定从源头入手，彻底梳理一套结合Ansible与带外管理接口的BMC初始化流程，确保每台上架的香港物理服务器都以标准化状态运行。本文将完整还原我落地这套方案的过程，涵盖IPMI认证、BMC参数下发、固件标准化、以及如何把这些流程编织进Ansible剧本中自动触发。
一、场景与需求剖析
我的目标很清晰：
- 每次新上架的香港裸金属服务器，必须先完成BMC账户初始化、网络配置、固件版本校验；
- 所有操作通过Ansible自动触发，避免人为接入；
- 覆盖Supermicro、DELL iDRAC、HPE iLO等主流厂商BMC，支持IPMI和Redfish协议；
- 最好能集成进我的现有Ansible部署管线中，作为前置任务。
二、方案架构设计
1. BMC访问方式梳理
香港机房中的带外管理一般采用如下架构：
运维PC/Ansible控制节点
│
└─── SSH + Ansible
│
├── 调用 IPMItool（用于Supermicro BMC）
├── 调用 Redfish API（用于DELL/HPE等）
└── 执行自定义脚本（用于固件检测和配置）
为了实现无人工接入，每台服务器的BMC IP、默认账户、品牌型号需提前纳入资产管理系统（如CMDB），Ansible剧本中动态引用。
三、Ansible剧本结构拆解
我将初始化流程拆成几个逻辑阶段，每个都使用一个playbook或role封装：
1. 初始化BMC账户与密码
以Supermicro为例，使用ipmitool命令添加并启用管理账户：
- name: Set BMC user and password
hosts: bmc_targets
gather_facts: no
tasks:
- name: Set admin password
shell: |
ipmitool -I lanplus -H {{ bmc_ip }} -U ADMIN -P ADMIN user set password 2 {{ new_password }}
delegate_to: localhost
对于iDRAC或iLO，采用Redfish模块：
- name: Update Redfish credentials
hosts: bmc_targets
tasks:
- name: Set new Redfish user
community.general.redfish_command:
category: ManagerAccount
command: CreateAccount
baseuri: "{{ bmc_ip }}"
username: root
password: calvin
new_username: ansibleadmin
new_password: "{{ new_password }}"
2. 配置BMC IP与VLAN（如适配独立管理网）
- name: Set static BMC IP
shell: |
ipmitool -I lanplus -H {{ bmc_ip }} -U {{ user }} -P {{ password }} lan set 1 ipsrc static
ipmitool -I lanplus -H {{ bmc_ip }} -U {{ user }} -P {{ password }} lan set 1 ipaddr {{ static_ip }}
ipmitool -I lanplus -H {{ bmc_ip }} -U {{ user }} -P {{ password }} lan set 1 netmask {{ netmask }}
ipmitool -I lanplus -H {{ bmc_ip }} -U {{ user }} -P {{ password }} lan set 1 defgw ipaddr {{ gateway }}
delegate_to: localhost
注意：该任务最好配合Ansible中的serial: 1串行执行，避免多个BMC同时变更IP引发ARP冲突。
3. 检测与升级BMC固件（避免接口行为异常）
这部分需要结合品牌定制工具。比如Supermicro可以使用sum工具或Redfish API获取固件版本：
- name: Check BMC firmware version
shell: ipmitool -I lanplus -H {{ bmc_ip }} -U {{ user }} -P {{ password }} mc info | grep 'Firmware Revision'
register: fw_output
delegate_to: localhost
- name: Assert version is latest
fail:
msg: "BMC firmware is outdated: {{ fw_output.stdout }}"
when: "'01.23' not in fw_output.stdout"
如需升级，可参考Redfish Upload Image或厂商批量升级工具（另写脚本挂载ISO或ROM）。
4. 添加启动日志钩子、关机触发器（可选）
某些平台（如DELL iDRAC）支持通过Redfish API配置自动Power Reset或启动后通知回调，这有助于更高阶的自动化触发：
- name: Configure boot event hook
community.general.redfish_command:
category: EventService
command: ConfigureDestination
baseuri: "{{ bmc_ip }}"
username: ansibleadmin
password: "{{ password }}"
destination: "http://monitoring.internal/api/bmc_event"
四、整合进完整自动化流程
为了避免单独执行BMC剧本，我将其作为主部署流程的前置任务。例如：
- name: Stage 0 - BMC Initialization
import_playbook: bmc-init.yaml
- name: Stage 1 - PXE Boot Provisioning
import_playbook: pxe-deploy.yaml
- name: Stage 2 - OS Ansible Roles
import_playbook: os-config.yaml
在Jenkins Pipeline或GitLab CI中，这部分也作为第一个Job触发，只有BMC初始化成功，后续裸金属安装才继续。
五、实战中遇到的问题与规避建议
BMC接口行为差异极大
一套代码跑所有厂商基本不现实，建议为Supermicro、DELL、HPE等维护独立角色，集中管理逻辑差异。
BMC默认账号安全风险
很多香港机房出厂账号为ADMIN/ADMIN或root/calvin，建议首次接入即统一强制修改。
Redfish兼容性不一
有些老旧BMC仅支持IPMI，Redfish调用将报错，因此要在Ansible中根据vendor变量动态分支协议。
带外网络应物理隔离
BMC接口常与业务网络不同，部署Ansible节点时务必确保其能访问带外VLAN，否则全部失败。
我通过这套方案，实现了在香港服务器上从BMC初始化到操作系统部署的完整闭环，彻底解决了早期频繁出现的“设备不可控”“初始化失败”等问题。更重要的是，这种方式可被轻易迁移到新厂商、新批次设备中，只要资产信息入库、网络畅通，Ansible就能无感知完成整个BMC配置工作。
裸金属的自动化部署，不应只关注PXE和系统配置，从带外管理入口统一服务器状态才是自动化的真正起点。这是我在实战中踩坑无数次后最深刻的体会。
