第二章 架构与运行机制

第二章 · 架构与运行机制

本章主线：上一章你已经能让引擎跑起来，本章跟着一条任务的完整旅程往引擎内部走——先看整台机器的构造（2.1），再看一条任务从 YAML 文本到远端系统调用的生命线（2.2），最后亲手用日志与计时工具把这条生命线摸一遍（2.3）。读完本章，你应当具备一种能力：当执行结果不符合预期时，知道去哪一层找原因。

很多教程跳过架构直接教语法，学习者于是长期停留在"照抄能跑、出错抓瞎"的状态。这条弯路的根源是把 Ansible 当成了一个黑盒加一堆语法糖。反过来，只要真正理解两件事——控制节点上有哪些部件、一条任务在受管节点上经历了什么——后文所有的语法细节都有了挂靠点：清单是给谁的输入，变量在哪个阶段解析，模块为什么写法特殊，回调插件为什么能改输出。本章的叙事顺序就按"部件图 → 生命线 → 实地勘察"推进。

一条任务的一生：先给个预告

在 2.2 节正式展开之前，先把结论预告在这里。当你在终端敲下 ansible-playbook 之后发生的事情，按顺序是：引擎读取配置与清单，把剧本解析成内部数据结构；变量引擎完成合并与渲染，确定每个 play 作用于哪些主机；策略插件决定任务的分发节奏（默认线性：所有主机完成当前任务才进下一任务）；对每个主机的每个任务，引擎通过连接插件建立 SSH 会话，把模块代码与参数打包送达远端，在远端 Python 环境执行，收回 JSON 结果；任务结果驱动状态记录与 handlers 通知；全部任务跑完后回调插件产出汇总。这套流程里每一步都有对应的插件类型，都有可调参数，也都是潜在的排障现场——2.3 节你会真的走进去。

本章三节怎么配合

2.1 整体架构解析负责"静态"：控制节点上的可执行入口、配置文件的查找顺序、清单与变量的加载路径、插件体系的全景，以及受管节点那一侧到底需要什么。读完你应当能回答"Ansible 到底装在了哪里、什么东西在哪一层"。

2.2 核心执行流程负责"动态"：上面那条预告的生命线逐站展开，重点是两个初学者最容易误解的机制——变量在何时渲染（不是边跑边渲染，而是按 play 的粒度先行渲染，这解释了大量"变量不生效"现象）和 handlers 的触发时机（攒到所在 play 的任务全部结束才执行，除非强制冲刷）。strategy 策略与 serial 滚动也在这一节讲透。

2.3 一次运行的链路跟踪实验是动手课：用详细度参数打出四层日志，装上计时回调看清每个任务的真实耗时，再用一段故意写错的剧本，观察错误在不同阶段的不同表现形态。这一节的产出是一套"勘察工具"，第 4 章的调试技巧与第 6 章的性能分析都建立在这套工具上。

读者需要的底子

知识点清单与自查

本章的可检验知识点如下：画出控制节点部件图并说出四个配置落点的优先级顺序（2.1）；解释无代理架构下受管节点的最低要求清单，以及网络设备为何走不同通道（2.1）；复述一条任务生命线的六个站点，并指出变量渲染发生在哪一站（2.2）；说明线性与自由两种策略的语义差异，以及 serial 批次的失败熔断规则（2.2）；解释 handlers 为什么延迟到 play 收尾执行、如何强制提前（2.2）；用四层详细度日志定位一类连通性错误，用计时回调找出最耗时的任务（2.3）。

本章与后续章节的接口

架构章的价值要在后续章节兑现，这里把接口提前标明。清单与变量的加载路径在本章只讲了位置，合并规则与优先级阶梯是 3.4 节的主题；插件体系在本章以"生命线上的零件"出现过名字，3.5 节给每类插件完整的索引与用法；策略插件的调度语义在本章确立，6.4 节的性能实验会给它配上实测数据；日志层次与错误形态在本章建立，4.4 节把它们升级成完整的排障流程。反过来说，如果读完后面章节感到某处"机制不明"，回本章查部件图往往比查语法手册更快——机制是语法的地基。带着这张接口图进入 2.1 节。