配置文件从哪来
ansible.cfg 决定并发度、连接参数、事实采集、提权默认值等全局行为。它按固定顺序查找：ANSIBLE_CONFIG 环境变量指向的文件、当前工作目录下的 ansible.cfg、家目录下的 ~/.ansible.cfg、最后是系统级 /etc/ansible/ansible.cfg。关键点是只取第一个找到的文件，不做多层合并，因此“在哪运行”会直接改变生效配置。
基本信息
| 查找顺序 | ANSIBLE_CONFIG → 当前目录 → 家目录 → 系统级（取首个命中） |
|---|---|
| 合并行为 | 不合并：只读取一个文件，其余文件的设置全部不生效 |
| 覆盖关系 | 命令行参数优先于环境变量，环境变量优先于配置文件 |
| 查看现状 | ansible-config dump 输出当前生效值，--only-changed 只列与默认值不同的项 |
| 查看可用项 | ansible-config list 列出全部配置项及其来源说明 |
| 常见分段 | defaults、ssh_connection、privilege_escalation、inventory、persistent_connection |
典型使用场景
- 项目自带配置：仓库根目录放 ansible.cfg，团队统一并发度与连接参数
- 临时排障：用 ANSIBLE_CONFIG 指向另一份配置，与项目配置对照验证
- CI 与人工执行行为一致：把关键项固化在仓库内的配置文件里而不是个人家目录
- 排查“我这台机器为什么不一样”：dump 出当前生效来源，确认读的是哪份文件
- 更换默认清单路径：在配置里指定 inventory 指向，避免每次敲 -i
- 审计影响面：评审一份新配置时逐段确认它改变了哪些默认行为
查看与临时切换
查看与临时切换
# 看当前生效值与来源
ansible-config dump --only-changed
# 列出全部可用配置项与说明
ansible-config list | head -40
# 查看当前读取的配置文件内容
ansible-config view
# 临时换一份配置执行，验证行为差异
ANSIBLE_CONFIG=/tmp/alt-ansible.cfg ansible-playbook -i inventory site.yml
# 用环境变量临时覆盖单项（优先级高于配置文件）
ANSIBLE_FORKS=20 ansible-playbook -i inventory site.yml常见项与影响面
| 配置项 | 影响 | 误配后果 |
|---|---|---|
| forks | 并发推进的主机数 | 过高压垮控制节点或目标机 |
| inventory | 默认清单路径 | 指向旧清单时操作到无关主机 |
| remote_user | 默认连接用户 | 用户不对则全部认证失败 |
| host_key_checking | 是否校验目标机主机密钥 | 关闭后中间人风险上升，便利但需权衡 |
| gathering | 默认事实采集策略 | 关闭后依赖事实的任务报未定义变量 |
| become 相关 | 默认是否提权与方式 | 全局开启后文件属主可能不符合预期 |
把关键配置固化在仓库里（项目根目录的 ansible.cfg）比放在个人家目录更可靠：个人配置只影响自己，别人执行同一 playbook 时行为不同，问题很难复现。团队场景应以仓库内配置为准，个人家目录只放与本地环境相关的项。
因为查找顺序里有“当前工作目录”，从不同目录执行同一个 playbook 可能读到完全不同的配置：在项目目录里跑是 50 并发，换到上一级目录跑就变回默认 5，甚至清单路径都变了。自动化脚本里应当固定工作目录或用 ANSIBLE_CONFIG 显式指定。
排查方法
遇到“同一份 playbook 在不同机器或不同人手上结果不同”，先跑 ansible-config dump --only-changed 对比两边的输出，差异项就是原因所在；再确认 ansible-config view 显示的是哪份文件。多数诡异问题最终都能落到“读的不是同一份配置”或“环境变量在起作用”这两类上。