📚 课程目录第1章课程导入与实验环境搭建

1. 课程导入与实验环境搭建

在数据中心里，一台 PowerEdge 服务器从开箱到上线，传统方式往往需要工程师推着键盘显示器进机房，逐台进入 BIOS、配置 RAID、设置 iDRAC 网络、挂载 ISO 装系统。当规模从 5 台变成 50 台、500 台时，这种"人肉运维"不仅慢，而且极易出现配置漂移——同一批机器里总有几台的固件版本、BIOS 设置或网卡参数不一致，后续排障时非常痛苦。自动化运维要解决的正是这个问题：把"一次性、手工、不可复现"的操作，变成"可描述、可批量、可重复"的代码与流程。

核心工具链：谁负责哪一段

Dell PowerEdge 的自动化能力不是单一工具，而是一条从带外管理到批量编排的工具链。理解每个工具所处的位置，比记住它们的名字更重要。

iDRAC（Integrated Dell Remote Access Controller）：服务器主板上独立的带外管理控制器，拥有自己的网口、IP 和固件。即使主机断电，只要电源线接着，iDRAC 就能工作。它是所有自动化的"最后一公里"执行者——电源控制、虚拟介质、BIOS/固件更新、硬件告警，最终都落到 iDRAC 上。
Redfish：基于 RESTful 的行业标准管理接口，用 HTTPS + JSON 描述资源。iDRAC 从 3.x 起提供完整的 Redfish 支持，路径形如 /redfish/v1/Systems/System.Embedded.1。它让自动化摆脱了厂商私有 CLI 的束缚，任何能发 HTTP 请求的语言都能管理服务器。
OMSA / iDRAC Service Module：OpenManage Server Administrator 是装在操作系统内的代理，提供主机侧的硬件监控与命令行工具 omreport；iDRAC Service Module（iSM）则把主机 OS 的信息回传给 iDRAC，让带外界面也能看到 OS 层状态。
OpenManage Enterprise（OME）：一对多的集中管理平台，负责发现、分组、合规基线、批量固件更新和配置部署。它面向"几百台"规模，是日常运维的控制台。
Ansible：无代理的编排引擎，通过 community.general.redfish_*、dellemc.openmanage 等集合调用 Redfish 或 OME API，把"配置一台"写成 playbook，再对成百上千台并行执行。

它们的关系可以概括为：OME 和 Ansible 是"指挥层"，Redfish 是"通信协议"，iDRAC 是"执行层"，OMSA/iSM 是"主机侧补充"。本课程后续所有批量操作，都建立在这条链路上。

实验环境规划

在动手之前，先把环境参数定下来。以下是一套可直接参考的示例规划，实际使用时请替换为你自己的网段与凭据。

项目	示例值	说明
管理网段	192.168.30.0/24	iDRAC 专用带外网络，与业务网隔离
网关	192.168.30.1	管理网网关
iDRAC 地址	192.168.30.101 ~ .103	三台实验机，按机架顺序编号
默认凭据	root / calvin	出厂默认，首次登录必须修改
控制节点	192.168.30.10	安装 Ansible 与 Python 的跳板机

第一步：配置 iDRAC 网络

新机出厂时 iDRAC 默认走 DHCP。如果管理网没有 DHCP 服务器，就需要通过前面板的 LCD 或 BIOS 里的 iDRAC Settings → Network 手工设置。以 BIOS 方式为例：开机按 F2 进入 BIOS，选择 iDRAC Settings，进入 Network 页，把 Enable NIC 设为 Enabled，NIC Selection 选 Dedicated（专用网口），IPV4 Settings 中关闭 DHCP，填入 192.168.30.101 / 255.255.255.0 / 192.168.30.1，保存后 iDRAC 会重启网络，约 30 秒后生效。

配置完成后，从控制节点验证连通性：

ping -c 3 192.168.30.101
# 预期：3 packets transmitted, 3 received, 0% packet loss

# 用 Redfish 读取 iDRAC 基本信息，验证接口可用
curl -sk -u root:calvin \
  https://192.168.30.101/redfish/v1/Managers/iDRAC.Embedded.1 \
  | python3 -m json.tool | head -20

返回的 JSON 中应包含 "ManagerType": "BMC"、"FirmwareVersion" 等字段。如果返回 401，说明凭据不对；返回超时则检查网线是否插在专用管理口、IP 是否与本地同网段。

首次登录 iDRAC Web 界面（https://192.168.30.101）时，系统会强制要求修改 root 密码。建议在实验环境中统一改为一个强密码并记录，后续 Ansible 的 redfish 模块会用到。

第二步：检查固件版本，建立基线

批量运维最怕"版本不一致"。在开始任何自动化之前，先采集每台机器的固件清单。Redfish 提供了 /redfish/v1/UpdateService/FirmwareInventory 端点，可以一次性列出所有可更新组件。

for ip in 192.168.30.101 192.168.30.102 192.168.30.103; do
  echo "=== $ip ==="
  curl -sk -u root:calvin \
    https://$ip/redfish/v1/UpdateService/FirmwareInventory \
    | python3 -c "
import sys, json
d = json.load(sys.stdin)
for m in d.get('Members', []):
    print(' ', m['@odata.id'].split('/')[-1])
"
done

示例输出会列出 BIOS、iDRAC、RAID.Integrated.1-1、NIC.Slot.3-1-1 等条目。再对每个条目取 Version 字段，就能得到一张固件基线表。判断标准很简单：同一型号、同一角色的服务器，关键组件（BIOS、iDRAC、RAID 控制器、网卡）版本应完全一致；若不一致，就需要在后续章节用 OME 或 Ansible 统一升级。

不要在生产窗口外随意升级 iDRAC 固件——升级过程中带外管理会中断数分钟，且部分机型要求先升级 iDRAC 再升级 BIOS，顺序错误可能导致更新失败。实验环境可放心操作，生产环境务必查阅对应机型的《固件更新顺序说明》。

第三步：验证自动化通路

环境搭好后，做一次最小闭环验证：用 Ansible 对三台机器并行执行一次只读的 Redfish 查询。在控制节点安装集合：

ansible-galaxy collection install dellemc.openmanage
pip install requests

编写一个最小 playbook，读取每台机器的电源状态：

- hosts: idrac
  gather_facts: false
  tasks:
    - name: 查询电源状态
      uri:
        url: "https://{{ inventory_hostname }}/redfish/v1/Systems/System.Embedded.1"
        user: root
        password: calvin
        force_basic_auth: true
        validate_certs: false
        return_content: true
      register: sys
    - debug:
        msg: "{{ inventory_hostname }} 电源状态 = {{ sys.json.PowerState }}"

若三台机器都返回 PowerState = On 或 Off，说明"控制节点 → Redfish → iDRAC"这条链路已经打通，后续的批量配置、固件升级、BIOS 设置都可以在此基础上展开。至此，实验环境准备完毕：iDRAC 网络可达、固件清单已采集、自动化通路已验证。