ansible 中的变量
- 一、ansible 中的变量
- 变量的定义
- 定义多个变量
- 引用变量
- 变量文件分离
- 二、setup模块
- 三、debug模块
- 四、在playbook获取到这些变量
一、ansible 中的变量
在ansible中使用变量,能让我们的工作变得更加灵活,在ansible中,变量的使用方式有很多种。
变量的定义
先说说怎样定义变量,变量名应该由字母、数字、下划线组成,变量名需要以字母开头,ansible内置的关键字不能作为变量名。
由于之前的几篇文章都是在通过剧本举例,所以我们先看怎样在playbook中使用变量。
如果我们想要在某个play中定义变量,可以借助vars关键字,示例如下
---
- hosts: testB
vars:
testvar1: testfile
remote_user: root
tasks:
- name: task1
file:
path: /testdir/{{ testvar1 }}
state: touch
上例中,先使用vars关键字,表示在当前play中进行变量的相关设置。
vars关键字的下一级定义了一个变量,变量名为testvar1,变量值为testfile
当我们需要使用testvar1的变量值时,则需要引用这个变量,如你所见,使用{{ 变量名 }}
可以引用对应的变量。
定义多个变量
也可以定义多个变量,示例如下。
vars:
testvar1: testfile
testvar2: testfile2
除了使用上述语法,使用YAML的块序列语法也可以定义变量,示例如下
vars:
- testvar1: testfile
- testvar2: testfile2
在定义变量时,还能够以类似”属性”的方式定义变量,示例如下
---
- hosts: testB
remote_user: root
vars:
httpd:
conf80: /etc/httpd/conf.d/80.conf
conf8080: /etc/httpd/conf.d/8080.conf
tasks:
- name: task1
file:
path: "{{httpd.conf80}}"
state: touch
- name: task2
file:
path: "{{httpd.conf8080}}"
state: touch
如上例所示,我定义了两个变量,两个变量的值对应两个httpd配置文件路径
vars:
httpd:
conf80: /etc/httpd/conf.d/80.conf
conf8080: /etc/httpd/conf.d/8080.conf
引用变量
当我们需要引用这两个变量时,有两种语法可用
语法一
"{{httpd.conf80}}"
语法二
"{{nginx['conf8080']}}"
这样使用变量在逻辑上比较清晰,可以看出conf80与conf8080都属于httpd相关的配置。
上例中,我在引用变量时使用了双引号,而在本文的第一个示例中引用变量时却没有使用双引号,这是因为,第一个示例中的变量在被引用时,并没有处于”开头的位置”,第一个示例中变量被引用时如下
path: /testdir/{{ testvar1 }}
当file模块的path参数引用对应的变量时,先写入了/testdir/
,然后才引用了testvar1
变量,{{ testvar1 }}
并没有处于”开头的位置”,换句话说就是,{{ testvar1 }}
前面还有字符串/testdir/
而在上述后面的示例中引用变量时,变量被引用时如下,处于”开头的位置”
path: "{{nginx.conf80}}"
这种情况下,我们引用变量时必须使用双引号引起被引用的变量,否则会报语法错误。
其实,上述情况也有例外
前文中有描述过,当在playbook中为模块的参数赋值时,可以使用”冒号”,也可以使用”等号”,当使用”等号”为模块的参数赋值时,则不用考虑引用变量时是否使用”引号”的问题,示例如下
---
- hosts: testB
remote_user: root
vars:
httpd:
conf80: /etc/httpd/conf.d/80.conf
conf8080: /etc/httpd/conf.d/8080.conf
tasks:
- name: task1
file:
path={{httpd.conf80}}
state=touch
- name: task2
file:
path={{httpd['conf8080']}}
state=touch
变量文件分离
除了能够在playbook中直接定义变量,我们还可以在某个文件中定义变量,然后再在playbook中引入对应的文件,引入文件后,playbook即可使用文件中定义的变量,你可能会问,为什么要多此一举呢?这是因为在某些工作场景中这样做很有用,比如,你想要让别人阅读你的playbook,却不想让别人看到某些值,可以使用这种办法,因为别人在阅读playbook时,只能看到引入的变量名,但是看不到变量对应的值,这种将变量分离到某个文件中的做法叫做”变量文件分离”,”变量文件分离”除了能够隐藏某些值,还能够让你将不同类的信息放在不同的文件中,并且让这些信息与剧本主体分开。
先来看看”变量文件分离”的一些小例子
首先,我们来定义一个专门用来存放httpd相关变量的文件(文件名为httpd_vars.yml),在文件中定义变量时,不要使用vars关键字,直接定义变量即可,定义变量的语法与在playbook中定义变量的几种语法相同
语法一示例:
testvar1: testfile
testvar2: testfile2
语法二示例:
- testvar1: testfile
- testvar2: testfile2
语法三示例:
httpd:
conf80: /etc/httpd/conf.d/80.conf
conf8080: /etc/httpd/conf.d/8080.conf
你可以选择你觉得较为舒适的语法定义变量,如下所示,直接在httpd_vars.yml文件中定义变量即可。
# cat httpd_vars.yml
httpd:
conf80: /etc/httpd/conf.d/80.conf
conf8080: /etc/httpd/conf.d/8080.conf
在httpd_vars.yml中定义完相关变量后,即可在playbook中引入文件中的变量,在playbook中引入包含变量的文件时,需要使用vars_files
关键字,被引入的文件需要以-
开头,以YAML中块序列的语法引入,示例如下
---
- hosts: testB
remote_user: root
vars_files:
- httpd_vars.yml
tasks:
- name: task1
file:
path={{httpd.conf80}}
state=touch
- name: task2
file:
path={{httpd['conf8080']}}
state=touch
上例中使用vars_files
关键字引入了对应的变量文件,然后使用了文件中定义的变量。
上例中vars_files
关键字只引入了一个变量文件,也可以引入多个变量文件,每个被引入的文件都需要以-
开头,示例如下
vars_files:
- /testdir/ansible/httpd_vars.yml
- /testdir/ansible/other_vars.yml
“vars”关键字和”vars_files”关键字可以同时使用,如下
vars:
- conf90: /etc/httpd/conf.d/90.conf
vars_files:
- /testdir/ansible/httpd_vars.yml
上文中已经初步的总结了变量的一些使用方法,下文我们继续,只不过,下文所涉及到的内容需要借助两个模块,所以在详细的总结变量的相关使用方法之前,会先描述一下这两个模块的用法。
二、setup模块
当我们运行一个playbook时,默认都会运行一个名为”[Gathering Facts]”的任务,前文中已经大致的介绍过这个默认的任务,ansible通过”[Gathering Facts]”这个默认任务收集远程主机的相关信息(例如远程主机的IP地址,主机名,系统版本,硬件配置等信息),其实,这些被收集到的远程主机信息会保存在对应的变量中,当我们想要使用这些信息时,我们可以获取对应的变量,从而使用这些信息。
如果想要查看”[Gathering Facts]”任务收集的信息内容,我们可以借助一个模块:setup模块
当执行playbook时,playbook其实就是自动调用了setup模块从而执行了”[Gathering Facts]”任务,所以我们可以通过手动执行setup模块查看”[Gathering Facts]”任务收集到的信息,示例如下
[root@server4 ~]# ansible testB -m setup
上述ad-hoc命令表示收集testB主机的相关信息,执行上述命令后,远程主机testB的相关信息将会输出到ansible主机的控制台上,返回的信息的格式是json格式,我的返回信息如下。
注:由于返回的信息比较多,此处为了方便示例,我将部分内容删除(或折叠省略)了,所以如下返回信息并不完全,只用于示意。
返回信息如上图,是一个json格式的字符串,为了方便你阅读,ansible已经将格式化后的json信息返回到了控制台中,返回的信息很全面,比如:
“ansible_all_ipv4_addresses”表示远程主机中的所有ipv4地址,从其对应的值可以看出,testB主机上一共有1个ipv4地址。
“ansible_distribution”表示远程主机的系统发行版,从其对应的值可以看出testB主机的系统发行版为Redhat
“ansible_distribution_version”表示远程主机的系统版本号,从其对应的值与 “ansible_distribution” 的值可以看出testB主机的系统版本为redhat7.3
“ansible_eth0″表示远程主机eth0网卡的相关信息。
“ansible_memory_mb”表示远程主机的内存配置信息。
返回的信息的确很多,很全面,但是,并不是每一次我们都需要看这么多信息,如果你只是想查看某一类信息,你可以通过关键字对信息进行过滤,比如,我只是想要查看远程主机的内存配置信息,那么我可以使用如下命令
[root@server4 ~]# ansible testB -m setup -a 'filter=ansible_memory_mb'
上述命令表示通过”ansible_memory_mb”关键字对返回信息进行过滤,如你所见,通过setup模块的filter参数可以指定需要过滤的关键字,这样ansible就只会将”ansible_memory_mb”的相关信息返回,返回如下
这样就精简很多了,因为精准的返回了你需要的信息,我知道,有的朋友可能跟我一样,记性不好,所以通常记不住准确的关键字,所以我们可以使用通配符,进行相对模糊的过滤,示例如下
[root@server4 ~]# ansible testB -m setup -a "filter=*mb*"
上述命令表示返回所有包含mb的关键字对应的信息,返回信息如下
其实,除了这些信息以外,我们还能够在远程主机中写入一些自定义的信息,这些自定义信息也可以被setup模块收集到。
那么,我们应该在哪里定义这些信息呢?该怎样定义这些信息呢?
ansible默认会去目标主机的/etc/ansible/facts.d
目录下查找主机中的自定义信息,并且规定,自定义信息需要写在以.fact
为后缀的文件中,同时,这些以.fact
为后缀的文件中的内容需要是INI格式或者是json格式的。
那么,我们来创建一个测试文件,测试文件路径为testB主机的/etc/ansible/facts.d/info.fact
,在文件中写入如下INI格式的信息。
[root@server3 ansible]# mkdir /etc/ansible/facts.d
[root@server3 ansible]# cd /etc/ansible/facts.d/
[root@server3 facts.d]# vim info.fact
[root@server3 facts.d]# cat info.fact
[testmsg]
msg1=This is the first custom test message
msg2=This is the second custom test message
如上所示,上述内容是一段INI风格的内容,我在”[testmsg]”配置段中配置了两条自定义信息,msg1与msg2。
当然,我们也可以使用json格式进行配置,比如在/etc/ansible/facts.d/info.fact
文件中写入如下配置,如下配置与上述配置的效果是相同的,只是书写格式不同。
{
"testmsg":{
"msg1":"This is the first custom test message",
"msg2":"This is the second custom test message"
}
}
通过上述方式,我们可以在目标主机的本地自定义信息,这些在远程主机本地自定义的信息被称为”local facts”,当我们运行setup模块时,远程主机的”local facts”信息也会被收集,我们可以通过”ansible_local”关键字过滤远程主机的”local facts”信息,示例命令如下
[root@server4 ~]# ansible testB -m setup -a "filter=ansible_local"
上述命令返回的信息如下
之前说过,当setup收集远程主机的”local facts”时,默认会查找远程主机的/etc/ansible/facts.d目录,如果你把”local facts”信息文件放在了其他自定义路径,在使用setup模块时,需要使用”fact_path”参数指定对应的路径,假设,我把”.fact”文件放在了目标主机的”/testdir”目录下,示例命令如下
[root@server4 ~]# ansible testB -m setup -a "fact_path=/testdir"
其实,setup模块返回的这些信息都存在了对应的变量中,我们可以通过引用变量从而使用对应的信息,但是别急,我们先来了解一下另外一个模块,这个模块叫”debug模块”。
三、debug模块
见名知义,debug模块的作用就是帮助我们进行调试的,debug模块可以帮助我们把信息输出到ansible控制台上,以便我们能够定位问题。
那么我们先来看一个debug模块的playbook小示例,如下
[root@server4 ~]# vim debug01.yml
[root@server4 ~]# cat debug01.yml
---
- hosts: testB
remote_user: root
tasks:
- name: touch testfile
file:
path: /testdir/testfile
state: touch
- name: debug demo
debug:
msg: this is debug info,The test file has been touched
上例中,我们先在test70主机上touch了对应的文件,然后,利用debug模块在控制台中输出了我们想要显示的信息,如你所见,debug模块的msg参数可以指定我们想要输出的信息,上述playbook表示touch完对应的文件以后,在ansible控制台中输出我们指定的信息,那么我们运行一下这个测试剧本,看一下效果,如下
[root@server4 ~]# ansible-playbook debug01.yml
如图所示,自定义信息已经输出在ansible控制台中。
debug模块除了能够使用msg参数输出自定义的信息,还能够直接输出变量中的信息,通过debug模块直接输出变量信息需要使用var参数,示例如下
[root@server4 ~]# vim debug02.yml
[root@server4 ~]# cat debug02.yml
---
- hosts: testB
remote_user: root
vars:
testvar: value of test variable
tasks:
- name: debug demo
debug:
var: testvar
上例虽然连接到了testB远程主机,但是并没有对testB做任何操作,只是在playbook中定义了一个变量,并且通过debug的var参数输出了这个变量的内容,只是为了单纯的演示debug模块的var参数的使用方法,上述playbook的执行效果如下
[root@server4 ~]# ansible-playbook debug02.yml
变量的名称以及变量的值都输出到了屏幕上,这个功能可以帮助我们调试playbook中变量,让我们了解变量的值是否符合我们的要求。
当然,使用debug的msg参数时也可以引用变量的值,这样我们自定义的信息就更加灵活了,示例如下。
[root@server4 ~]# vim debug03.yml
[root@server4 ~]# cat debug03.yml
---
- hosts: testB
remote_user: root
vars:
testvar: testv
tasks:
- name: debug demo
debug:
msg: "value of testvar is : {{testvar}}"
上例中的msg自定义信息中引用了testvar变量的值
注:上例中msg的值需要使用引号引起,因为{{testvar}}变量前包含”冒号”,如果不使用引号会报语法错误。
上例输出效果如下
四、在playbook获取到这些变量
setup模块与debug模块了解完了,现在绕回一开始的话题,playbook在运行时默认都会运行”[Gathering Facts]”任务,”[Gathering Facts]”任务会收集远程主机的相关信息,这些信息会保存在对应的变量中,我们在playbook中可以使用这些变量,从而利用这些信息,那么我们怎样在playbook获取到这些变量的值呢?在setup模块的示例中,我们可以通过”ansible_memory_mb”关键字获取远程主机的内存信息,其实,”ansible_memory_mb”就是一个变量名,换句话说就是,我们可以在playbook中直接引用名为”ansible_memory_mb”的变量,从而获取到远程主机的内存信息,示例如下
[root@server4 ~]# vim debug04.yml
[root@server4 ~]# cat debug04.yml
---
- hosts: testB
remote_user: root
tasks:
- name: debug demo
debug:
msg: "Remote host memory information: {{ansible_memory_mb}}"
上例执行效果如下
[root@server4 ~]# ansible-playbook debug04.yml
如图所示,我们自定义的信息中包含了远程主机的内存信息,同时被输出了,只是格式上没有手动执行setup模块返回的信息格式易读,手动执行setup模块获取到的内存信息返回如下
testB | SUCCESS => {
"ansible_facts": {
"ansible_memory_mb": {
"nocache": {
"free": 1487,
"used": 336
},
"real": {
"free": 1151,
"total": 1823,
"used": 672
},
"swap": {
"cached": 0,
"free": 1023,
"total": 1023,
"used": 0
}
}
},
"changed": false
}
如上述返回信息所示,”ansible_memory_mb”中其实包含了 “nocache”、”real”、 “swap”三个部分的信息,如果我们只想获得”real”部分的信息,在playbook中引用变量时可以使用如下两种语法(即相当于使用属性调用变量)。
语法一示例:
debug:
msg: "Remote host memory information : {{ansible_memory_mb.real}}"
语法二示例:
debug:
msg: "Remote host memory information : {{ansible_memory_mb['real']}}"
[root@server4 ~]# vim debug04.yml
[root@server4 ~]# cat debug04.yml
---
- hosts: testB
remote_user: root
tasks:
- name: debug demo
debug:
msg: "Remote host memory information: {{ansible_memory_mb.real}}"
上述两种语法前文中已经进行过示例,此处不再赘述。
其实,这些远程主机的变量信息不仅仅能够用于输出,我们通常会获取到这些信息以后,对这些信息的值进行判断,判断是否符合我们的要求,然后再执行下一步动作,比如,先获取到远程主机的系统发行版信息,然后判断发行版是centos6还是centos7,如果是centos6,我们就将准备好的A文件拷贝到远程主机中,如果是centos7,我们就将准备好的B文件拷贝到远程主机中。