3. Ansible 核心架构回顾：控制节点与受管节点、Inventory、Module、Playbook、Role 的职责与交互流程

在深入配置漂移检测与环境一致性基线核验之前，必须重新梳理 Ansible 的核心架构组件及其协作关系。Ansible 采用无代理（Agentless）架构，通过 SSH 或 WinRM 协议从控制节点向受管节点推送指令，其核心组件包括：控制节点、受管节点、Inventory、Module、Playbook 和 Role。理解这些组件的职责与交互流程，是构建可靠基线核验体系的基础。

3.1 组件职责一览

3.2 交互流程：从 Playbook 到受管节点

一次典型的 Ansible 任务执行流程如下：

1. 加载 Inventory：控制节点读取 Inventory 文件或动态脚本，确定目标主机列表与分组。
2. 解析 Playbook：控制节点读取 Playbook YAML，解析其中定义的 hosts、tasks、vars、roles 等。
3. 收集 Facts：默认在 Play 开始时，控制节点通过 setup 模块自动收集受管节点的系统信息（Facts），用于条件判断与变量引用。
4. 任务分发：控制节点将每个任务对应的 Module 及其参数打包，通过 SSH/WinRM 连接发送至受管节点。
5. 本地执行：受管节点上的 Python 解释器执行 Module 脚本，完成具体操作（如检查文件状态、安装软件包）。
6. 结果返回：受管节点将执行结果（JSON 格式，包含 changed、failed、msg 等字段）返回给控制节点。
7. 结果处理：控制节点根据返回结果决定是否继续执行后续任务、触发 Handler 或报告失败。

3.3 核心交互架构图

下图展示了 Ansible 核心组件之间的数据流与控制流关系：

3.4 Role 在基线核验中的特殊地位

在配置漂移检测与环境一致性基线核验场景中，Role 是最核心的复用单元。一个标准的基线核验 Role 目录结构如下：

roles/
└── baseline_check/
    ├── tasks/
    │   ├── main.yml          # 入口任务，调用各子任务
    │   ├── check_os.yml      # 检查 OS 版本与内核参数
    │   ├── check_services.yml # 检查关键服务状态
    │   ├── check_files.yml   # 检查配置文件权限与校验和
    │   └── check_security.yml # 检查安全基线项
    ├── vars/
    │   └── main.yml          # 基线期望值定义（版本号、路径、权限等）
    ├── templates/
    │   └── baseline_report.j2 # 生成基线核验报告模板
    ├── files/
    │   └── custom_check.sh   # 自定义校验脚本
    └── defaults/
        └── main.yml          # 默认变量，可被 Playbook 覆盖

3.5 组件交互的时序关系

下图以时间轴方式展示一次基线核验 Playbook 执行过程中各组件的交互顺序：

3.6 组件交互中的关键设计原则

• 幂等性：Module 设计保证多次执行结果一致，这是基线核验可重复性的基础。
• 声明式 vs 过程式：Playbook 描述期望状态（声明式），Module 内部实现过程式操作。
• 变量作用域：Inventory 变量 > Playbook 变量 > Role defaults 变量 > Role vars 变量，优先级明确，避免基线期望值被意外覆盖。
• 连接协议：默认 SSH，支持 Paramiko（纯 Python）和 OpenSSH 两种后端；Windows 受管节点使用 WinRM。
• Facts 缓存：基线核验场景建议启用 Facts 缓存（fact_caching=jsonfile），避免重复采集，提升大规模环境执行效率。