2.1 整体架构解析

2.1 整体架构解析

本节摘要：把 Ansible 拆成"控制节点上的部件"与"受管节点上的最低要求"两侧，讲清各入口命令、配置查找顺序、清单与插件体系的挂靠位置。核心结论：Ansible 是一套跑在控制机上的 Python 工具集，受管机只欠 SSH 与 Python。

控制节点上都装了什么

用包管理器安装 Ansible 之后，机器上多出来的东西可以归成四类。第一类是入口命令：ansible（临时命令）、ansible-playbook（跑剧本）、ansible-inventory（查看清单解析结果）、ansible-config（查看配置）、ansible-doc（查模块文档）、ansible-galaxy（管理角色与集合）、ansible-vault（加密）。这些命令同属一个 Python 包，共享同一套配置与插件加载机制——理解了这一点，"为什么 ansible 能用的模块 ansible-playbook 也能用"这类问题就自动消解了。

第二类是引擎本体：任务队列管理、变量渲染、策略调度、连接管理。它大部分时间作为 ansible-playbook 进程存在，单进程多工作线程（默认上限由 forks 配置控制，默认值为 5）。这个单进程模型是后面第 6 章性能调优的物理基础——所谓并发调优，调的就是这一个进程对外发连接的方式。

第三类是内容：内置模块库如今归入 ansible.builtin 集合，外加从公共仓库安装的社区集合。引擎与内容解耦是 2020 年后的架构大事，细节第 4.2 节展开。

第四类是配置。配置文件有四个可能的落点，优先级从高到低依次为：环境变量、当前目录的配置文件、用户主目录下的配置、系统级配置。引擎沿执行目录向上查找，先找到哪个用哪个——这就是"项目内放一份配置、随仓库走"做法的原理。常用配置项值得背下来几条：

# 项目根目录下的 ansible.cfg（节选）
[defaults]
inventory = ./inventory/production.ini   ; 默认清单位置
forks = 20                                ; 并发上限，默认 5
host_key_checking = False                 ; 实验环境可关，生产建议保持开启
gathering = smart                         ; 事实收集策略，配合缓存使用
callbacks_enabled = profile_tasks         ; 启用耗时统计回调（第 2.3 节会用）

[ssh_connection]
pipelining = True                         ; SSH 管道加速，大规模场景必开
​

配置的坑大多出在查找顺序上：明明改了系统配置却没生效，往往是因为项目目录里躺着一份更早被找到的配置。排查命令是 ansible-config dump --only-changed，它告诉你当前生效的全部非默认值与来源。

受管节点那一侧

答案极简：SSH 服务、Python 解释器、一个可用的提权通道（如 sudo）。模块送达远端后，引擎在目标机的临时目录生成一段 Python 代码，找到合适的解释器执行，输出 JSON，然后删除痕迹。没有常驻进程、没有监听端口、没有自启动项——这正是 1.1 节"无代理"承诺在架构上的兑现。

两种例外值得知道。其一是没有 Python 的设备（大量网络设备、部分极简容器镜像），走"模块走 HTTP 或本地模式"的替代路径，由专门的网络集合处理。其二是不需要 SSH 的本机操作：连接插件换成 local，任务直接在控制机执行，常用于剧本里对控制机自身的编排动作。

部件全景图

把两侧合起来看。控制节点一侧，从上到下是入口命令、执行引擎、清单与变量、插件池、配置层；虚线以下是 SSH 通道与远端最低要求。记这张图的时候抓三条主线：配置决定引擎行为，清单与剧本是引擎的两份输入，插件池是引擎每个环节的可替换零件。

图 2-1：Ansible 整体架构全景

从架构看清两类高频问题

第一类，"为什么我的配置没生效"。四个配置落点的优先级加沿目录向上查找规则，覆盖了绝大多数此类疑惑；用 ansible-config dump 验证，一分钟定位。第二类，"为什么这台机器连不上或模块报错"。回到受管侧的最低要求清单：SSH 通吗，Python 在吗，sudo 通道好吗——三个问题各有对应的验证命令（ssh 手工登录、ansible host -m setup、ansible host -b -m command -a id）。

入口命令的分工速查

四个配置落点之外，控制节点的日常使用还依赖入口命令的正确分工，一张速查表胜过记忆。临时执行用 ansible（单模块、单次、配合清单模式）；流程执行用 ansible-playbook（多任务、多 play、handlers 与 serial 在这里才生效）；核对清单用 ansible-inventory（--list 看合成结果、--graph 看组树）；查文档用 ansible-doc（-l 搜索、-s 速查）；管内容用 ansible-galaxy（角色与集合的装、查、建）；加密用 ansible-vault（create、edit、encrypt_string、view）；核对配置用 ansible-config（dump --only-changed 看生效值）。分工的判断标准只有一条：想让引擎进哪个站点工作，就用哪个入口——临时验证走 ansible，完整流程走 ansible-playbook，这条线划清后，命令选择不再需要思考。

架构位置的选型含义

本节的部件图还有一个远期用法：评估其他工具时快速判断它的架构取舍。看到任何新自动化工具，先问三个对应问题：它的"引擎"在哪跑（控制侧形态与资源占用）、它的"清单与变量"怎么组织（数据模型）、它的扩展点在哪（插件位的多少与文档化程度）。三个问题的答案拼出来，工具的能力边界基本就清楚了——架构分析的迁移价值大于任何单点结论。举例来说，某个按需触发的执行器与某个常驻收敛系统，无论宣传语如何，第一问的答案就分出了它们各自适合的变更节奏。这也是把架构章放在全书前部的原因：它给的不是知识，是看同类问题的透镜。

部件健康度的周期核对

部件图除了排障，还能当周期体检的底图，每月一次的核对清单如下：配置层——ansible-config dump 的输出与上月对比，意外出现的非默认值要能说清来源；清单层——ansible-inventory --graph 的组树与资产台账对差，新增与消失的机器要有解释；插件层——项目里启用的回调与连接插件列表复核一遍，测试期临时启用的配置是否忘记撤下；内容层——集合列表与 requirements 的锁定值比对，确认没有游离安装的集合。四项核对合计半小时，产出一份"部件健康快照"存档。这个习惯的本质与 6.3 节的合规自检同构：让系统状态可核对、可留痕，漂移就无处藏身。部件图的真正价值也在此——它不只是讲解用的插图，而是你这台"自动化引擎"的保养手册封面。