在清单中配置变量：
在清单中，可以配置需要被管理的远程主机，也可以将部分远程主机分为一组，其实，在配置清单时，还可以为主机或主机组设置变量，具体方法见如下总结：
1.主机变量
在清单中配置远程主机时，可以同时为主机配置对应的变量，当操作这个主机时，即可直接使用对应的变量。
比如，我在/etc/ansible/hosts中定义192.168.10.2主机时，可以为该主机配置一个名为testvar的变量，变量值为test_host_var1，示例如下：
192.168.10.2 testvar=test_host_var1
192.168.10.2 testvar=test_host_var1,var2,var3,var4 ###定义多个变量
经过测试可见：
[root@ansible-control ansible]# ansible 192.168.10.2 -m shell -a "echo {{testvar}}"
192.168.10.2 | CHANGED | rc=0 >>
test_host_var1
操作192.168.10.2主机时，testvar已经被引用到了，当然，testvar是192.168.10.2的主机变量，其他主机并不能引用到这个变量，主机变量的生效范围只限于对应的主机。
2.主机组变量：
在清单中，我们能将多个主机分为一组，这样方便我们成批的操作远程主机。
比如，我在清单中将192.168.10.2与192.168.10.3分为一组，组名为testALL，INI格式的配置如下：
[testALL] test-dot-2 ansible_host=192.168.10.2 ###test-dot-2是给主机192.168.10.2取的一个别名 test-dot-3 ansible_host=192.168.10.3
现在开始为主机组testALL配置组变量，示例如下：（组变量属于某一组的公共变量，仅供该组内的主机使用）
[testALL] test-dot-2 ansible_host=192.168.10.2 test-dot-3 ansible_host=192.168.10.3 [testALL:vars] test_group_var1='group var test' test_group_var2='group var test2'
如上例所示，“[testALL:vars]”表示为testALL组配置变量，上例中，testALL组中一共定义了两个组变量，“test_group_var1”和“test_group_var2”
组变量的使用范围为组中的所有主机，上例中，无论test-dot-2还是test-dot-3，都可以使用到上述两个变量，效果如下：
3.通过set_fact定义变量
set_fact是一个模块，我们可以通过set_fact模块在tasks中定义变量，先来看一个小示例，如下：
---
- hosts: 192.168.10.2
remote_user: root
tasks:
- set_fact:
testvar: "testtest"
- debug:
msg: "{{testvar}}"
如上例所示，我们通过set_fact模块定义了一个名为testvar的变量，变量值为testtest，然后使用debug模块输出了这个变量。
是不是很简单，通过set_fact模块就能够在tasks中定义变量了，我们也可以通过set_fact将一个变量的值赋予另一个变量，示例如下：
---
- hosts: 192.168.10.2
remote_user: root
vars:
testvar1: test1_string
tasks:
- shell: "echo test2_string"
register: shellreturn
- set_fact:
testsf1: "{{testvar1}}"
testsf2: "{{shellreturn.stdout}}"
- debug:
msg: "{{testsf1}} {{testsf2}}"
上例中，我们先定义了一个变量testvar1，又使用register将shell模块的返回值注册到了变量shellreturn中，
之后，使用set_fact模块将testvar1变量的值赋予了变量testsf1，将shellreturn变量中的stdout信息赋值给了testsf2变量，
最后，使用debug模块输出了testsf1与testsf2的值。
如上述示例所示，set_fact模块可以让我们在tasks中创建变量，也可以将一个变量的值赋值给另一个变量。
前文中已经总结过，默认情况下，每个play执行之前都会执行一个名为“[Gathering Facts]”的默认任务，这个任务会收集对应主机的相关信息，我们可以称这些信息为facts信息，我们已经总结过怎样通过变量引用这些facts信息，此处不再赘述，而通过set_fact模块创建的变量可以在之后play中被引用，就好像主机的facts信息可以在play中引用一样，这样说可能还是不是特别容易理解，不如来看一个小例子，如下：
---
- hosts: 192.168.10.2
remote_user: root
vars:
testvar1: tv1
tasks:
- set_fact:
testvar2: tv2
- debug:
msg: "{{testvar1}}----{{testvar2}}"
- hosts: 192.168.10.2
remote_user: root
tasks:
- name: other play get testvar2
debug:
msg: "{{testvar2}}"
- name: other play get testvar1
debug:
msg: "{{testvar1}}"
上例中一共有两个play，第一个play中，我们通过两种方式创建了两个变量，第一个变量testvar1使用vars关键字创建，第二个变量使用set_fact创建。
如果执行上例的playbook，可以发现，这两个变量在第一个play中都可以正常的输出。但是在第二个play中，testvar2可以被正常输出了，testvar1却不能被正常输出，会出现未定义testvar1的错误，因为在第一个play中针对test70主机进行操作时，testvar1是通过vars关键字创建的，而testvar2是通过set_fact创建的，所以testvar2就好像192.168.10.2的facts信息一样，可以在第二个play中引用到，而创建testvar1变量的方式则不能达到这种效果，虽然testvar2就像facts信息一样能被之后的play引用，但是在facts信息中并不能找到testvar2，只是“效果上”与facts信息相同罢了。