Ansible变量评估与gather_facts的关联问题分析

问题背景

在Ansible自动化工具的使用过程中，变量评估是一个核心功能。然而，近期发现了一个有趣的现象：某些变量的评估结果竟然与gather_facts参数的设置有关。这一发现揭示了Ansible内部变量处理机制中一个值得注意的特性。

问题重现

通过以下示例可以清晰地重现该问题：

- hosts: localhost
  gather_facts: '{{ facts }}'
  vars:
    myvar_x: "{{ {'a': 'b'} }}"
  tasks:
    - debug: var=myvar_x
    - set_fact:
        myvar: >-
          {{
            vars | dict2items |
            selectattr('key', 'match', '^myvar_') |
            map(attribute='value') |
            map('combine') | combine
          }}
    - debug: var=myvar['a']

当分别执行ansible-playbook -i localhost, -e 'facts=true' test.yml和ansible-playbook -i localhost, -e 'facts=false' test.yml时，会得到不同的结果：

• 当gather_facts=true时，myvar['a']输出为"VARIABLE IS NOT DEFINED!"
• 当gather_facts=false时，myvar['a']正确输出为"b"

技术分析

这一现象的根本原因在于直接操作Ansible内部数据结构vars的不稳定性。vars是Ansible内部使用的数据结构，其内容和行为可能会受到各种因素的影响，包括但不限于gather_facts的设置。

正确的变量处理方法

Ansible官方推荐使用专门的查找插件来处理变量，而不是直接操作vars数据结构。具体来说：

1. varnames查找插件：用于获取匹配特定模式的变量名列表
2. vars查找插件：用于安全地获取指定变量的值

改进后的示例如下：

- hosts: localhost
  gather_facts: '{{ facts }}'
  vars:
    myvar_x: "{{ {'a': 'b'} }}"
    myvar_y: "{{ {'c': 'd'} }}"
  tasks:
    - debug: var=myvar_x
    - debug: var=myvar_y
    - set_fact:
        myvar_providers: '{{ lookup("ansible.builtin.varnames", "^myvar_") }}'
    - debug: var=myvar_providers
    - set_fact:
        myvar: '{{ myvar | default({}) | combine(lookup("ansible.builtin.vars", item)) }}'
      loop: '{{ myvar_providers.split(",") }}'
    - debug: var=myvar['a']

这种方法更加健壮，不受gather_facts设置的影响，能够稳定地获取预期的变量值。

最佳实践建议

1. 避免直接操作内部数据结构：如vars、hostvars等内部数据结构可能会因Ansible版本或运行环境而变化
2. 使用官方提供的查找插件：vars和varnames查找插件是专门设计用于安全访问变量的工具
3. 考虑变量作用域：理解Ansible中变量的不同作用域（全局、主机、组等）对变量访问的影响
4. 测试不同场景：特别是在使用gather_facts时，验证变量访问逻辑的正确性

结论

这一案例展示了Ansible变量处理中的一个微妙之处，强调了遵循官方推荐实践的重要性。通过使用专门的查找插件而非直接操作内部数据结构，可以确保Playbook在各种配置下都能稳定运行。对于需要从多个变量源合并配置的场景，采用查找插件的方法既安全又可靠。