Ansible Playbook Variables
{{ foo [ 0 ] }}
Magic Variables, and How To Access Information About Other Hosts
即使您没有自己定义它们，Ansible会为您自动提供一些变量。 其中最重要的是hostvars ， group_names和groups 。 用户不应该自己使用这些名称，因为它们是保留的。environment也保留。
hostvars可让您询问另一个主机的变量，包括已经收集到关于该主机的事实。 如果在这一点上，你还没有在剧本或剧集中玩过这个主机，那么你仍然可以得到这些变量，但是你将无法看到事实。
如果您的数据库服务器想要使用另一个节点的“事实”值，或者分配给另一个节点的清单变量，那么在一个模板甚至一个动作行中可以轻松实现：
{{ hostvars [ ' test.example.com' ] [ 'ansible_distribution' ] }}
另外， group_names是当前主机所有组的列表（数组）。这可以在使用Jinja2语法的模板中使用，以使得根据主机的组成员资格（或角色）而变化的模板源文件
{% if 'webserver' in group_names %}
# some part of a configuration file that only applies to webservers
{% endif %}
groups是清单中所有组（和主机）的列表。 这可以用于枚举组内的所有主机。 例如：
{% for host in groups['app_servers'] %}
# something that applies to all app servers.
{% endfor %}
一个经常使用的成语是走一个组来查找该组中的所有IP地址
{% for host in groups['app_servers'] %}
{{ hostvars['ansible_eth0']['ipv4']['address'] }}
{% endfor %}
一个例子可能包括将前端代理服务器指向所有应用服务器，在服务器之间设置正确的防火墙规则等。您需要确保这些主机的事实已经填充，例如，通过运行如果事实最近还没有被缓存，那么他们就会玩这个游戏（在Ansible 1.8中添加了事实缓存）。
此外， inventory_hostname是在Ansible的清单主机文件中配置的主机名的名称。 当您不想依赖于发现的主机名ansible_hostname或其他神秘原因时，这可能很有用。 如果你有一个很长的FQDN， inventory_hostname_short也包含第一个时间段，没有其余的域。
play_hosts在2.2中已被弃用，它与新的ansible_play_batch变量相同。
新版本2.2。
ansible_play_hosts是当前播放中仍然有效的所有主机的完整列表。
新版本2.2。
ansible_play_batch可用作播放当前“批”的范围内的主机名列表。 批量大小由serial定义，当不设置它相当于整个播放（使其与ansible_play_hosts相同）。
版本2.3中的新功能。
ansible_playbook_python是用于调用可执行命令行工具的python可执行文件的路径。
这些变量可能对于填写具有多个主机名的模板或将列表注入到负载均衡器的规则中是有用的。
除非你认为你需要，否则不要担心这些。 你会知道你什么时候做的
inventory_dir也是可用的目录，该目录包含Ansible的库存主机文件， inventory_file是路径名，文件名指向Ansible的库存主机文件。
playbook_dir包含playbook基本目录。
然后我们有role_path ，它将返回当前角色的路径名（自1.8）。 这只能在一个角色中发挥作用。
最后， ansible_check_mode （在版本2.1中添加），一个布尔魔术变量，如果您使用--check运行可执行文件，则将其设置为True 。
Variable File Separation
这是一个很好的主意，让您的Playbook受到源代码的控制，但您可能希望将Playbook的来源公开，同时保留某些重要的变量。 同样，有时您可能只想将某些信息保存在不同的文件中，远离main playbook。
您可以通过使用外部变量文件或文件来执行此操作，如下所示：
---
- hosts: all
remote_user: root
vars:
favcolor: blue
vars_files:
- /vars/external_vars.yml
tasks:
- name: this is just a placeholder
command: /bin/echo foo
这可以消除与他人共享您的手册源的敏感数据的风险。
每个变量文件的内容是一个简单的YAML字典，如下所示：
---
# in the above example, this would be vars/external_vars.yml
somevar: somevalue
password: magic
Passing Variables On The Command Line
除了vars_prompt和vars_files ，还可以通过可执行命令行发送变量。 在编写通用发行版手册时，您可能希望通过要部署的应用程序版本，这一点尤其有用：
ansible-playbook> 这对于设置play的主机组或用户而言非常有用。
---
- hosts: '{{ hosts }}'
remote_user: '{{ user }}'
tasks:
- ...
ansible-playbook> 从Ansible 1.2开始，您还可以传入额外的var，如引用的JSON，如下所示：
--extra-vars'{“pacman”：“mrs”，“ghosts”：[“inky”，“pinky”，“clyde”，“sue”]}
key=value形式显然更简单，但是如果需要它就在那里！
从Ansible 1.3起，可以使用@语法从JSON文件中加载额外的var：
--extra-vars“@ some_file.json”
也可以从Ansible 1.3，额外的vars可以格式化为YAML，无论是在命令行还是在上面的文件中。
Variable Precedence: Where Should I Put A Variable?
很多人可能会问，变量如何覆盖另一个。 最终，Ansible的理念是更好地知道在哪里放一个变量，然后你必须考虑一下。
避免在47个位置定义变量“x”，然后询问“哪个x被使用”的问题。 为什么？ 因为那不是禅宗的做事哲学。
只有一个帝国大厦。 一个蒙娜丽莎等，找出定义变量的位置，不要复杂。
但是，让我们继续前进吧！ 它存在 这是一件真实的事情，你可能会用它。
如果在不同的地方定义了相同名称的多个变量，则它们将按照一定的顺序被覆盖。
在1.x中，优先级如下（最后列出的变量获得优先级排序）：
[*] “role defaults”，其优先于所有事物，并且是最容易被覆盖的
[*]inventory中定义的变量
[*]在有关系统中发现的facts
[*] “most everything else”（命令行开关，play中的变量，include变量，角色变量等）
[*]连接变量（ ansible_user等）
[*]额外的vars（ -e在命令行中）最优先
注意
在1.5.4之前的版本中，有关系统的事实发现在上述的“其他一切”类别中。
在2.x中，我们使优先顺序更具体（最后列出的变量获得优先级排序）：
[*]role defaults
[*]inventory文件或脚本组vars
[*]inventory group_vars / all
[*] playbook group_vars / all
[*]inventory group_vars / *
[*] playbook group_vars / *
[*]inventory 文件或脚本主机vars
[*]inventory host_vars / *
[*] playbook host_vars / *
[*]host facts
[*]play facts
[*]play vars_prompt
[*]play vars_files
[*] role vars（在role / vars / main.yml中定义）
[*]block 变量（仅适用于块中的任务）
[*]任务变量（仅用于任务）
[*]角色（和include_role）参数
[*]include参数
[*] include_vars
[*] set_facts / registered vars
[*]额外的vars（总是赢得优先）
基本上，进入“角色默认值”（角色中的默认文件夹）的任何东西都是最有价值的，容易被覆盖的。 该角色的vars目录中的任何内容都会覆盖该命名空间中该变量的先前版本。 这里要遵循的一个想法是，在范围上越明确，命令行-e额外的vars总是胜出越多的优先级。 主机和/或库存变量可以胜过角色默认值，但不显式包括vars目录或include_vars任务。
页:
[1]