ansible playbook中的变量相关介绍(一)----setup与debug模块

ゞ浴缸里的玫瑰 2023-07-20 12:26 18阅读 0赞

## 1.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

在定义变量时，还能够以类似”属性”的方式定义变量，示例如下

---
    - 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}}"

语法二

"{ {htppd['conf8080']}}"

这样使用变量在逻辑上比较清晰，可以看出conf80与conf8080都属于httpd相关的配置。

上例中，我在引用变量时使用了双引号，而在本文的第一个示例中引用变量时却没有使用双引号，这是因为，第一个示例中的变量在被引用时，并没有处于”开头的位置”，第一个示例中变量被引用时如下

path: /testdir/{ {  testvar1 }}

当file模块的path参数引用对应的变量时，先写入了/testdir/，然后才引用了testvar1变量，\{ \{ testvar1 \}\}并没有处于”开头的位置”，换句话说就是，\{ \{ testvar1 \}\}前面还有字符串/testdir/

而在上述后面的示例中引用变量时，变量被引用时如下，处于”开头的位置”

path: "{ {htppd.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

语法三示例：

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

上文中已经初步的总结了变量的一些使用方法，下文我们继续，只不过，下文所涉及到的内容需要借助两个模块，所以在详细的总结变量的相关使用方法之前，会先描述一下这两个模块的用法。

## 2.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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70]  
上述命令表示收集testB主机的相关信息，执行上述命令后，远程主机testB的相关信息将会输出到ansible主机的控制台上，返回的信息的格式是json格式，我的返回信息如下。

注：由于返回的信息比较多，此处为了方便示例，我将部分内容删除（或折叠省略）了，所以如下返回信息并不完全，只用于示意。

返回信息如上图，是一个json格式的字符串，为了方便你阅读，ansible已经将格式化后的json信息返回到了控制台中，返回的信息很全面，比如：

“ansible\_all\_ipv4\_addresses”表示远程主机中的所有ipv4地址，从其对应的值可以看出，testB主机上一共有1个ipv4地址。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 1]  
返回的信息的确很多，很全面，但是，并不是每一次我们都需要看这么多信息，如果你只是想查看某一类信息，你可以通过关键字对信息进行过滤，比如，我只是想要查看远程主机的内存配置信息，那么我可以使用如下命令

[root@server4 ~]# ansible testB -m setup -a 'filter=ansible_memory_mb'

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 2]  
上述命令表示通过”ansible\_memory\_mb”关键字对返回信息进行过滤，如你所见，通过setup模块的filter参数可以指定需要过滤的关键字，这样ansible就只会将”ansible\_memory\_mb”的相关信息返回，返回如下

这样就精简很多了，因为精准的返回了你需要的信息，我知道，有的朋友可能跟我一样，记性不好，所以通常记不住准确的关键字，所以我们可以使用通配符，进行相对模糊的过滤，示例如下

[root@server4 ~]# ansible testB -m setup -a "filter=*mb*"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 3]  
其实，除了这些信息以外，我们还能够在远程主机中写入一些自定义的信息，这些自定义信息也可以被setup模块收集到。

那么，我们应该在哪里定义这些信息呢？该怎样定义这些信息呢？

ansible默认会去目标主机的/etc/ansible/facts.d目录下查找主机中的自定义信息，并且规定，自定义信息需要写在以.fact为后缀的文件中，同时，这些以.fact为后缀的文件中的内容需要是INI格式或者是json格式的。

那么，我们来创建一个测试文件，测试文件路径为testB主机的/etc/ansible/facts.d/info.fact，在文件中写入如下INI格式的信息。  
在server3主机

[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"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 4]  
之前说过，当setup收集远程主机的`local facts`时，默认会查找远程主机的`/etc/ansible/facts.d`目录，如果你把`local facts`信息文件放在了其他自定义路径，在使用setup模块时，需要使用”fact\_path”参数指定对应的路径，假设，我把”.fact”文件放在了目标主机的`/testdir`目录下，示例命令如下

[root@server4 ~]# ansible testB -m setup -a "fact_path=/testdir"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 5]  
其实，setup模块返回的这些信息都存在了对应的变量中，我们可以通过引用变量从而使用对应的信息，但是别急，我们先来了解一下另外一个模块，这个模块叫”debug模块”。

## 3.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

上例中，我们先在test主B机上touch了对应的文件，然后，利用debug模块在控制台中输出了我们想要显示的信息，如你所见，debug模块的msg参数可以指定我们想要输出的信息，上述playbook表示touch完对应的文件以后，在ansible控制台中输出我们指定的信息，那么我们运行一下这个测试剧本，看一下效果，如下

[root@server4 ~]# ansible-playbook debug01.yml

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 6]  
如图所示，自定义信息已经输出在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的执行效果如下  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 7]  
变量的名称以及变量的值都输出到了屏幕上，这个功能可以帮助我们调试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\}\}变量前包含”冒号”，如果不使用引号会报语法错误。

上例输出效果如下  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 8]

## 4.在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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 9]  
如图所示，我们自定义的信息中包含了远程主机的内存信息，同时被输出了，只是格式上没有手动执行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']}}"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 10]  
上述两种语法前文中已经进行过示例，此处不再赘述。

其实，这些远程主机的变量信息不仅仅能够用于输出，我们通常会获取到这些信息以后，对这些信息的值进行判断，判断是否符合我们的要求，然后再执行下一步动作，比如，先获取到远程主机的系统发行版信息，然后判断发行版是centos6还是centos7，如果是centos6，我们就将准备好的A文件拷贝到远程主机中，如果是centos7，我们就将准备好的B文件拷贝到远程主机中。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70]: /images/20230528/60dbab93659249c4bb61f720126a7e78.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 1]: /images/20230528/ab03782fc6964603b22dbf1913574cf6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 2]: /images/20230528/9364947fb1764ddb8c6aeb5559070b66.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 3]: /images/20230528/015b15c11efe4be58a1e51de6e257178.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 4]: /images/20230528/b97dd80e0dd14c25b16f19306371ee3c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 5]: /images/20230528/d715db7c6a3841848a1bac1c795f6b33.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 6]: /images/20230528/96c9af07c8f247a6b92d3776ef6d6433.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 7]: /images/20230528/aee0297aeaa64f31b8fc07be4daf71e6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 8]: /images/20230528/dac385259fee4e6a81f5282bb3d01ddf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 9]: /images/20230528/e9f082855e62418bbe44f337035be860.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 10]: /images/20230528/006698f9eda24f2cbe6b1a4a5277dd10.png