在清单中配置变量:
在清单中,可以配置需要被管理的远程主机,也可以将部分远程主机分为一组,其实,在配置清单时,还可以为主机或主机组设置变量,具体方法见如下总结:
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信息相同罢了。