ansible笔记(18):变量(五)

栏目: 服务器 · 发布时间: 6年前

内容简介:所属分类:ansible
  • A+

所属分类:ansible 运维技术

在本博客中,ansible是一个系列文章,我们会尽量以通俗易懂的方式总结ansible的相关知识点。

ansible系列博文直达链接:ansible轻松入门系列

"ansible系列"中的每篇文章都建立在前文的基础之上,所以, 请按照顺序阅读这些文章,否则有可能在阅读中遇到障碍。

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

内置变量ansible_version

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

ansible test70 -m debug -a "msg={{ansible_version}}"

内置变量hostvars

除了ansible_version,还有一些非常有用的内置变量。比如内置变量hostvars

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

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

---
- name: "play 1: Gather facts of test71"
 hosts: test71
 remote_user: root
 
- name: "play 2: Get facts of test71 when operating on test70"
 hosts: test70
 remote_user: root
 tasks:
 - debug:
     msg: "{{hostvars['test71'].ansible_ens35.ipv4}}"

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

"{{hostvars.test71.ansible_ens35.ipv4}}"

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

---
- name: "play 1: Gather facts of test71"
 hosts: test71
 remote_user: root
 gather_facts: no
 
 
- name: "play 2: Get facts of test71 when operating on test70"
 hosts: test70
 remote_user: root
 tasks:
 - debug:
     msg: "{{hostvars['test71'].ansible_ens35.ipv4}}"

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

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

---
- hosts: test71
 remote_user: root
 gather_facts: no
 tasks:
 - shell: "echo register_var_in_play1"
   register: shellreturn
  
- hosts: test70
 remote_user: root
 gather_facts: no
 tasks:
 - debug:
     msg: "{{hostvars.test71.shellreturn.stdout}}"

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

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

---
- hosts: test71
 remote_user: root
 gather_facts: no
 vars:
   testvar: testvar_in_71
 tasks:
 - debug:
     msg: "{{testvar}}"
 
 
- hosts: test70
 remote_user: root
 gather_facts: no
 tasks:
 - debug:
     msg: "{{hostvars.test71.testvar}}"

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

---
- hosts: test71
 remote_user: root
 gather_facts: no
 tasks:
 - set_fact:
     testvar: "testvar_in_71"
 - debug:
     msg: "{{testvar}}"
- hosts: test70
 remote_user: root
 gather_facts: no
 tasks:
 - debug:
     msg: "{{hostvars.test71.testvar}}"

上例通过"set_fact"结合"hostvars"的方式,实现了跨play获取其他主机中的变量信息的功能,还是很方便的。

内置变量inventory_hostname

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

[test_group]
10.1.1.60
test70.zsythink.net ansible_host=10.1.1.70
test71 anisble_host=10.1.1.71

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

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

# ansible test_group -m debug -a "msg={{inventory_hostname}}"
test70.zsythink.net | SUCCESS => {
   "changed": false,
   "msg": "test70.zsythink.net"
}
10.1.1.60 | SUCCESS => {
   "changed": false,
   "msg": "10.1.1.60"
}
test71 | SUCCESS => {
   "changed": false,
   "msg": "test71"
}

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

内置变量inventory_hostname_short

与内置变量inventory_hostname类似,通过inventory_hostname_short也可以获取当前play操作的主机在清单中对应的名称,但是这个名称更加简短,假设我的清单配置如下

[test_group]
10.1.1.60
test70.zsythink.net ansible_host=10.1.1.70
test71 anisble_host=10.1.1.71

那么通过内置变量inventory_hostname_short获取到的主机的简短名称如下:

# ansible test_group -m debug -a "msg={{inventory_hostname_short}}"
test70.zsythink.net | SUCCESS => {
   "changed": false,
   "msg": "test70"
}
10.1.1.60 | SUCCESS => {
   "changed": false,
   "msg": "10"
}
test71 | SUCCESS => {
   "changed": false,
   "msg": "test71"
}

可以看到,无论是IP还是别名,如果清单的主机名称中包含".",inventory_hostname_short都会取得主机名中第一个"."之前的字符作为主机的简短名称。

内置变量play_hosts

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

---
- hosts: test70,test71
 remote_user: root
 gather_facts: no
 tasks:
 - debug:
     msg: "{{play_hosts}}"

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

TASK [debug] *************************
ok: [test70] => {
   "msg": [
       "test71",
       "test70"
   ]
}
ok: [test71] => {
   "msg": [
       "test71",
       "test70"
   ]
}

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

没错,inventory_hostname和play_hosts都是返回主机名,只不过,inventory_hostname只返回当前被操作的主机的主机名,而play_hosts则返回当前play中所有被操作主机的主机名列表。

内置变量groups

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

10.1.1.60
test70.zsythink.net ansible_host=10.1.1.70
test71 anisble_host=10.1.1.71
 
[testA]
test60 ansible_host=10.1.1.60
test61 ansible_host=10.1.1.61
 
[testB]
test70 ansible_host=10.1.1.70
 
[test:children]
testA
testB

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

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

# ansible test70 -m debug -a "msg={{groups}}"
test70 | SUCCESS => {
   "changed": false,
   "msg": {
       "all": [
           "10.1.1.60",
           "test70.zsythink.net",
           "test71",
           "test60",
           "test61",
           "test70"
       ],
       "test": [
           "test60",
           "test61",
           "test70"
       ],
       "testA": [
           "test60",
           "test61"
       ],
       "testB": [
           "test70"
       ],
       "ungrouped": [
           "10.1.1.60",
           "test70.zsythink.net",
           "test71"
       ]
   }
}

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

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

# ansible test70 -m debug -a "msg={{groups.test}}"

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

# ansible test70 -m debug -a "msg={{groups['test']}}"

聪明如你一定已经会举一反三了,所以,如果我们想要获取到所有未分组主机的主机名,则可以使用如下方法

# ansible test70 -m debug -a "msg={{groups.ungrouped}}"

内置变量group_names

见名知义,我们可以通过内置变量group_names获取到当前主机所在分组的组名,比如,我的清单配置如下

10.1.1.60
test70.zsythink.net ansible_host=10.1.1.70
test71 anisble_host=10.1.1.71
 
[testA]
test60 ansible_host=10.1.1.60
test61 ansible_host=10.1.1.61
 
[testB]
test70 ansible_host=10.1.1.70
 
[test:children]
testA
testB

那么,当我操作test70主机时,group_names变量值如下

# ansible test70 -m debug -a "msg={{group_names}}"
test70 | SUCCESS => {
   "changed": false,
   "msg": [
       "test",
       "testB"
   ]
}

如上例返回值所示,test70主机属于testB组,而testB组又是test组的子组,所以test70主机同时属于testB组和test组,所以,最终返回的信息中包括test与testB

当我们操作未分组的主机时,group_names的值为"ungrouped",示例如下

# ansible 10.1.1.60 -m debug -a "msg={{group_names}}"
10.1.1.60 | SUCCESS => {
   "changed": false,
   "msg": [
       "ungrouped"
   ]
}

内置变量inventory_dir

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

# ansible test71 -m debug -a "msg={{inventory_dir}}"
test71 | SUCCESS => {
   "changed": false,
   "msg": "/etc/ansible"
}

这篇文章就先总结到这里,希望能够对你有所帮助。

我的微信公众号

关注"实用运维笔记"微信公众号,当博客中有新文章时,可第一时间得知哦~


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Traction: A Startup Guide to Getting Customers

Traction: A Startup Guide to Getting Customers

Gabriel Weinberg、Justin Mares / S-curves Publishing / 2014-8-25 / USD 14.99

Most startups end in failure. Almost every failed startup has a product. What failed startups don't have is traction -- real customer growth. This book introduces startup founders and employees to......一起来看看 《Traction: A Startup Guide to Getting Customers》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

SHA 加密
SHA 加密

SHA 加密工具

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具