Ansible（十五）-- ansible 中的变量（四）内置变量 ansible_version hostvars inventory_hostname 等

梦里梦外; 2023-07-18 14:28 12阅读 0赞

### ansible 中的内置变量 ###

*  一、内置变量ansible\_version
 *  二、内置变量hostvars
 *  三、内置变量inventory\_hostname
 *  四、内置变量inventory\_hostname\_short
 *  五、内置变量play\_hosts
 *  六、内置变量groups
 *  七、内置变量group\_names
 *  八、内置变量inventory\_dir

ansible中还有一些内置变量可供我们使用，当然，这些内置变量的变量名是被ansible保留的，我们定义变量时不能使用这些变量名。

# 一、内置变量ansible\_version #

先从一个简单的内置变量说起，比如，我们可以通过内置变量ansible\_version获取到ansible的版本号，示例命令如下

[root@server4 ~]# ansible testB -m debug -a "msg={ {ansible_version}}"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70]

# 二、内置变量hostvars #

除了ansible\_version，还有一些非常有用的内置变量。比如内置变量hostvars

hostvars可以帮助我们在操作当前主机时获取到其他主机中的信息。

假设，我想要在操作test70主机时获取到test71主机中的facts信息，我该怎么办呢？示例如下

[root@server4 ~]# vim nz.yml
    [root@server4 ~]# cat nz.yml 
    ---
    - name: "play 1: Gather facts of testC"
      hosts: testC
      remote_user: root
    
    - name: "play 2: Get facts of testC when operating on testB"
      hosts: testB
      remote_user: root
      tasks:
      - debug:
          msg: "{ {hostvars['testC'].ansible_eth0.ipv4}}"

上例中有两个play，第一个play针对testC主机执行，但是第一个play中没有显式指定任何task（后文会解释原因），第二个play针对testB主机执行，在第二个play中只有一个task，即使用debug模块，输出了testC主机中的eth0网卡的IP信息，如你所见，我们可以借助hostvars在操作当前主机时输出其他主机中的facts信息，上例中使用hostvars加上清单中的主机名称再加上facts的key，即可获取到对应的facts信息，有了前文的总结作为基础，你一定想到了，上例中的msg的值改为如下写法也是可以的。

"{ {hostvars.testC.ansible_eth0.ipv4}}"

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 1]  
上例中的第一个play中并没有任何的task，为什么还需要第一个play呢？如果你将上例的第一个play删除，只保留第二个play，运行时则会报错，这是因为，虽然第一个play中没有任何task，但是当第一个play执行时，默认会调用”\[Gathering Facts\]”任务，也就是说，默认会收集testC主机的facts信息，**只有被收集过的facts信息才能被后面的play引用到**，如果压根没有收集对应主机的facts信息，即使使用hostvars内置变量，也无法获取到对应主机的facts信息，我们来做个试验，我们可以直接把上例的第一个play从playbook中删除，也可以指明让第一个play不收集对应的facts信息，使用”gather\_facts”关键字可以控制当前play是否收集对应主机的facts信息，示例如下:

[root@server4 ~]# vim nz.yml
    [root@server4 ~]# cat nz.yml 
    ---
    - name: "play 1: Gather facts of testC"
      hosts: testC
      remote_user: root
      gather_facts: no
    
    - name: "play 2: Get facts of testC when operating on testB"
      hosts: testB
      remote_user: root
      tasks:
      - debug:
          msg: "{ {hostvars['testC'].ansible_eth0.ipv4}}"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 2]

如上例所示，第一个play中的”gather\_facts: no”表示设置当前play不收集对应主机的信息，运行上例playbook会报错，因为第二个play在操作testB时，无法获取到testC主机中的facts信息，原因是testC的facts信息并未被收集过，所以，调用其他主机的facts信息的前提是对应主机的facts信息已经被收集过。

其实，除了facts信息，我们还能够利用hostvars内置变量从别的主机中获取到其他类型的一些变量信息，比如，其他主机的注册变量、主机变量、组变量等信息，我们先来看一个获取其他主机的注册变量的小示例，如下：

[root@server4 ~]# vim nz1.yml
    [root@server4 ~]# cat nz1.yml 
    ---
    - hosts: testC
      remote_user: root
      gather_facts: no
      tasks:
      - shell: "echo register_var_in_play1"
        register: shellreturn
    
    - hosts: testB
      remote_user: root
      gather_facts: no
      tasks:
      - debug:
          msg: "{ {hostvars.testC.shellreturn.stdout}}"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 3]

如上例所示，通过hostvars内置变量可以直接获取到其他主机中的注册变量，你一定发现了，**注册变量并不用像facts信息那样需要事先收集，即可直接通过hostvars跨主机被引用到**，同理，如果你在清单中为testC主机配置了主机变量，或者为testC主机所在的组配置了组变量，也是可以通过hostvars直接跨主机引用的。

你可能会问，如果我直接在play中为当前主机定义一个变量，可以在之后的play中操作其他主机时被引用到吗？那么我们来做个实验，示例如下  
我的清单配置如下：

172.25.63.2
    testB.redhat.com ansible_host=172.25.63.1
    testC ansible_host=172.25.63.6
    
    
    [testA]
    test1 ansible_host=172.25.63.3
    test2 ansible_host=172.25.63.5
    
    [testB]
    test3 ansible_host=172.25.63.4
    
    [test:children]
    testA
    testB

[root@server4 ~]# vim nz2.yml
    [root@server4 ~]# cat nz2.yml 
    ---
    - hosts: testC
      remote_user: root
      gather_facts: no
      vars:
        testvar: testvar_in_C
      tasks:
      - debug:
          msg: "{ {testvar}}"
    
    - hosts: testB
      remote_user: root
      gather_facts: no
      tasks:
      - debug:
          msg: "{ {hostvars.testC.testvar}}"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 4]

在上例的第一个play中我们为test71主机定义了一个变量，变量名称为testvar，在第二个play中操作test70主机时，使用hostvars尝试引用test71主机中的变量，如果执行上述playbook则会报错，看来通过vars关键字定义的变量使用上例中的方法是无法被跨主机引用的，前一篇文章中，我们总结了怎样使用”set\_fact”关键字定义变量，通过”set\_fact”关键字定义的变量拥有类似”facts”信息的特性（如果不明白可以参考前文），所以，我们可以把”vars”关键字中定义的变量通过”set\_fact”关键字去定义，这样这些变量就好像facts信息被收集过一样，能被之后的play引用到了，示例如下

[root@server4 ~]# vim nz2.yml
    [root@server4 ~]# cat nz2.yml 
    ---
    - hosts: testC
      remote_user: root
      gather_facts: no
      tasks:
      - set_fact:
          testvar: testvar_in_C
      - debug:
          msg: "{ {testvar}}"
    
    - hosts: testB
      remote_user: root
      gather_facts: no
      tasks:
      - debug:
          msg: "{ {hostvars.testC.testvar}}"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 5]

上例**通过”set\_fact”结合”hostvars”的方式，实现了跨play获取其他主机中的变量信息的功能**，还是很方便的。

# 三、内置变量inventory\_hostname #

通过inventory\_hostname变量可以获取到被操作的当前主机的主机名称，这里所说的主机名称并不是linux系统的主机名，而是对应主机在清单中配置的名称，假设我的清单配置如下

[test-group]
    172.25.63.5
    testB.redhat.com ansible_host=172.25.63.3
    testC ansible_host=172.25.63.6

清单中配置了三个主机，第一个主机以IP的形式配置，第二个主机和第三个主机都以别名的方式配置，他们同属于test\_group组。

那么我们使用内置变量inventory\_hostname获取一下各个主机的对应的主机名，看看会返回什么，示例如下

[root@server4 ~]# ansible test-group -m debug -a "msg={ {inventory_hostname}}"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 6]

从返回信息可以看出，如果使用IP配置主机，inventory\_hostname的值就是IP，如果使用别名，inventory\_hostname的值就是别名。

# 四、内置变量inventory\_hostname\_short #

与内置变量inventory\_hostname类似，通过inventory\_hostname\_short也可以获取当前play操作的主机在清单中对应的名称，**但是这个名称更加简短**。

那么通过内置变量inventory\_hostname\_short获取到的主机的简短名称如下：

[root@server4 ~]# ansible test-group -m debug -a "msg={ {inventory_hostname_short}}"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 7]

可以看到，无论是IP还是别名，如果清单的主机名称中包含`.`，inventory\_hostname\_short都会**取得主机名中第一个”.”之前的字符作为主机的简短名称。**

# 五、内置变量play\_hosts #

通过内置变量play\_hosts可以获取到当前play所操作的所有主机的主机名列表，示例playbook如下：

[root@server4 ~]# vim nz3.yml
    [root@server4 ~]# cat nz3.yml 
    ---
    - hosts: testB,testC
      remote_user: root
      gather_facts: no
      tasks:
      - debug:
          msg: "{ {play_hosts}}"

执行上例的playbook，返回信息如下

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 8]  
我的清单配置如下：

可以看到，此play每操作一个主机，都会将当前play操作的所有主机的主机名列表返回。

没错，inventory\_hostname和play\_hosts都是返回主机名，只不过，**inventory\_hostname只返回当前被操作的主机的主机名，而play\_hosts则返回当前play中所有被操作主机的主机名列表**。

# 六、内置变量groups #

通过groups内置变量可以获取到清单中”所有分组”的”分组信息”，什么意思呢？我们先来看一个清单配置，假设我的清单配置如下：

上述清单中，显式的指定了三个组，testA组、testB组、test组，其中，testA组与testB组是test组的子组，除了组中的主机，还有三台主机没有任何分组，直接写在了清单中。

现在，我们获取一下groups变量的值，看看会返回哪些信息，随便操作清单中的任意一台主机即可，示例如下

[root@server4 ~]# ansible testB -m debug -a "msg={ {groups}}"
    test3 | SUCCESS => { 
        "msg": { 
            "all": [
                "172.25.63.2", 
                "testB.redhat.com", 
                "testC", 
                "test1", 
                "test2", 
                "test3"
            ], 
            "test": [
                "test1", 
                "test2", 
                "test3"
            ], 
            "testA": [
                "test1", 
                "test2"
            ], 
            "testB": [
                "test3"
            ], 
            "ungrouped": [
                "172.25.63.2", 
                "testB.redhat.com", 
                "testC"
            ]
        }
    }

从上述返回信息可以看出，所有主机默认被分成了组名为”all”的组，testA组中有两台主机，testB组中有一台主机，由于testA组和testB组都属于test组的子组，所以testA组与testB组中的主机都属于test组，由于有三台主机在清单中并未分组，所以，ansible自动将没有分组的主机分到了名为”ungrouped”的组中，即组名为”未分组”的组。

我们还能够通过组名，获取到指定组的分组信息，假设，我想要获取到上例中testA组中的主机名称，则可以使用如下方法。

[root@server4 ~]# ansible testB -m debug -a "msg={ {groups.testA}}"

![在这里插入图片描述][20200329142628777.png]

当然，语法也可以改为如下

# ansible testB -m debug -a "msg={ {groups['testA']}}"

所以，如果我们想要获取到所有未分组主机的主机名，则可以使用如下方法

[root@server4 ~]# ansible testB -m debug -a "msg={ {groups.ungrouped}}"

![在这里插入图片描述][20200329142818523.png]

# 七、内置变量group\_names #

见名知义，我们可以通过内置变量group\_names获取到当前主机所在分组的组名，比如，我的清单配置和上例相同。

那么，当我操作test1主机时，group\_names变量值如下

[root@server4 ~]# ansible test1 -m debug -a "msg={ {group_names}}"

![在这里插入图片描述][20200329142942472.png]  
如上例返回值所示，test1主机属于testB组，而testB组又是test组的子组，所以test1主机同时属于testB组和test组，所以，最终返回的信息中包括test与testB

当我们操作未分组的主机时，group\_names的值为”ungrouped”，示例如下

[root@server4 ~]# ansible 172.25.63.2 -m debug -a "msg={ {group_names}}"

![在这里插入图片描述][20200329143029674.png]

# 八、内置变量inventory\_dir #

我们可以通过inventory\_dir变量获取到ansible主机中清单文件的存放路径，我使用的是默认的清单文件/etc/ansible/hosts，所以，inventory\_dir变量对应的值为/etc/ansible，如下例所示

[root@server4 ~]# ansible test1 -m debug -a "msg={ {inventory_dir}}"

![在这里插入图片描述][20200329143112562.png]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70]: /images/20230528/54cc4ecdb4544b1789d773fffd26f7c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 1]: /images/20230528/aa53237e30c14173a0f652e71ab5c577.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 2]: /images/20230528/fad7ba28a8d746cc8255e95c9992d0eb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 3]: /images/20230528/b5a0410bd21c47e0a18e77e34ff56dd6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 4]: /images/20230528/dae2a7cea67d4d3595ae8bfe81effc01.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 5]: /images/20230528/23be3c652eb446e5b9b99015f10d866e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 6]: /images/20230528/388b7dc517514ef1ab2e6b9e42754d98.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 7]: /images/20230528/1d914f9d04094f88b1d112cc53979eea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 8]: /images/20230528/11de3fb2f7ac49dc92596433994c5b20.png
[20200329142628777.png]: /images/20230528/3e23d5dd53cc44b59107f3ad5ef4c180.png
[20200329142818523.png]: /images/20230528/3a8cff749cba45f7b5217c5327adf036.png
[20200329142942472.png]: /images/20230528/64694f797f284bb1b1a854a0c7f05458.png
[20200329143029674.png]: /images/20230528/9e5f4c3483da4c379191a9554442e446.png
[20200329143112562.png]: /images/20230528/eba91794e06248b388ad38d4ebd75389.png