主机自己提供的事实
除了内置事实，被管主机也可以自己提供事实：在 /etc/ansible/facts.d/ 放 .fact 文件（内容为 INI 或 JSON）或可执行脚本，采集后结果出现在 ansible_local 命名空间下。自定义事实适合表达内置探测拿不到的信息，比如这台机器在业务里的角色、所在机房、允许的维护窗口，让元数据随主机走，而不是全部堆在控制端的变量文件里。
基本信息
| 默认目录 | /etc/ansible/facts.d/，可用 fact_path 调整 |
|---|---|
| 文件形式 | .fact 后缀的 INI 或 JSON，或可执行脚本 |
| 读取路径 | ansible_local.<文件名>.<节或键> |
| 生效时机 | 每次采集事实时读取，不依赖缓存传递 |
典型使用场景
- 表达机器所属业务分组、机房位置、维护窗口等内置事实拿不到的元数据
- 让脚本探测本机定制信息（某个中间件的实际部署目录）并作为事实暴露
- 与集中式变量文件的取舍：机器重建后仍能自带角色信息，减少仓库改动
- 刚注册完成的机器首次运行就能读到本地事实，不必先同步变量
- 与运行期内存变量的区别：本地事实每次采集都重新读取，不靠缓存传递
事实文件与读取
事实文件与读取
# /etc/ansible/facts.d/site.fact（INI 形式，也可写 JSON）
[app]
tier = web
zone = cn-north
# 可执行脚本需有可执行权限并向标准输出打印 JSON
# 变量引用示例（playbook 中）：
# - ansible.builtin.debug:
# msg: "本机角色 {{ ansible_local.site.app.tier }}"三种元数据载体
| 方式 | 存放位置 | 特点 |
|---|---|---|
| 本地事实 | 被管主机目录 | 随主机携带，需要主机侧权限与重建流程配合 |
| 分组与主机变量 | 控制端仓库 | 集中管理，可版本控制，机器重建需重新分配 |
| 运行期内存变量 | 单次运行内 | 仅当次有效，可写缓存供后续运行读取 |
文件名与节名都会成为变量路径的一部分，改动名称等于改掉所有引用点，属于破坏性变更：要么同步修改引用的 playbook，要么新老并存一段时间。
可执行脚本会以采集事实的身份运行，脚本报错可能让整次采集失败；脚本应快速返回并只输出合法 JSON，不要在里面做耗时探测或写入其他文件。
与变量文件的分工
判断标准是这条信息的归属：它描述的是机器自身的事实（在哪个机房、属于哪个业务域），就放在主机侧；它是运维策略（用哪个版本、开哪些开关），就放在控制端的变量文件里。两边都放会带来双份真相，改了一处忘了另一处时排查成本最高。