ansible变量、机密、事实

文章目录

ansible变量、机密、事实

variables :变量
vaults :机密
facts :事实

变量简介:

​ 为什么要设定变量?能让我们的工作变得更加灵活,将 playbook 中的某些值使用变量代替,可以简化项目的创建和维护,并减少错误的数量,变量是用来存储数据和引用数据.

通过变量,可以轻松地在Ansible项目中管理给定环境的动态值。例如,变量可能包含下面这些值:

  • 要重新启动的服务
  • 要删除的文件
  • 要从互联网检索的存档
  • 要创建的用户
  • 要安装的软件包

变量名的定义:

变量名必须以字母开头,不能有空格,只能包含字母,数字和下划线,ansible内置的关键字不能作为变量名。

无效和有效的ansible变量名示例:

无效的变量名 有效的变量名
user name user_name
become sudo brcome_sudo
1st file file_1
file1
remoteserver$1 remote_server_1
remote_server1

变量定义的范围

​ 可以在Ansible项目中的多个位置定义变量。不过,这些变量大致可简化为三个范围级别:

  • play范围:在play和相关结构中设置的变量

  • 主机范围:由清单、事实收集或注册的任务,在主机组和个别主机上设置的变量

  • 全局范围:从命令行或Ansible配置设置的变量

    如果在多个级别定义了相同名称的变量,则采用优先级别最高的变量。窄范围优先于更广泛的范围:由清单定义的变量将被playbook定义的变量覆盖,playbook定义的将被命令行中定义的变量覆盖。

playbook中的变量

​ 变量在Ansible Playbook中发挥着重要作用,因为它们可以简化playbook中变量数据的管理。

playbook中的变量

​ 编写playbook时,可以定义自己的变量,然后在任务中调用这些值。Playbook变量可以通过多种方式定义。一种常见的方式是将变量放在playbook开头的vars块中:

---
 - name: test
   hosts: 192.168.220.8
   vars:      # 变量
     user: tom
     home: /home/tom
   tasks:     # 任务
   ....

​ 也可以在在playbook中指定变量文件。此时不使用playbook中的vars块,可以改为使用vars_files指令,后面跟上相对于playbook位置的外部变量文件名称列表:。

---
 - name: test
   gather_facts: on
   hosts: 192.168.220.8
   vars_files:
     - vars/user.yml     #相对于playbook位置的外部变量文件名称列表

YAML格式的 vars/user.yml 变量文件内容

user: lishi
home: /etc/lisi

文件位置

 tree /etc/ansible
/etc/ansible
├── ansible.cfg
├── inventory
├── roles
├── test.yml   # 运行的是这个文件
└── vars
    └── user.yml  # 变量是写在这里面的

在Playbook中使用变量

在playbook中声明了变量后,可以在任务中使用这些变量。若要引用变量,可以将变量名放在双大括号内。在任务执行时,Ansible会将变量替换为其值。

注意:当变量用作开始一个值的第一元素时,必须使用引号。这可以防止Ansible将变量引用视为YAML字典的开头。

---
 - name: test
   hosts: 192.168.220.8
   gather_facts: no
   vars:
     user: tom
   tasks:
     - name: test
       user:
         name: "{{ user }}"   # 变量用作开始一个值的第一元素时,必须使用引号
         state: present 

主机变量和组变量

方法一:

直接应用于主机的清单变量分为两类:

  • 主机变量,应用于特定主机

  • 组管理,应用于一个主机组或一组主机组中的所有主机

    主机变量优先于组变量,但playbook中定义的变量的优先级比这两者更高。

    若要定义主机变量和组变量,一种方法是直接在清单文件中定义。这是较旧的做法,不建议采用, 但你可能会在未来的工作当中遇到。

    定义192.168.220.8的ansible_user主机变量

[client]
192.168.220.8 ansible_user=tom

定义client主机组的user组变量

[clients]
192.168.220.8
192.168.220.9

[clients:vars]
user=tom

定义clients组的user组变量,该组由两个主机组成,每个主机组有两个服务器:

[clients01]
node1.example.com
node2.example.com

[clients02]
node3.example.com
node4.example.com

[clients:children]
clients01
clients02

[clients:vars]
user=tom

这种做法存在一些缺点,它使得清单文件更难以处理,在同一文件中混合提供了主机和变量信息,而且采用的也是过时的语法。

方法二:

使用目录填充主机和组变量

​ 定义主机和主机组的变量的首选做法是在与清单文件或目录相同的工作目录中,创建group_vars和host_vars两个目录。这两个目录分别包含用于定义组变量和主机变量的文件。

​ 建议的做法是使用host_vars和group_vars目录定义清单变量,而不直接在清单文件中定义它们。

​ 为了定义用于clients组的组变量,需要创建名为group_vars/clients的YAML文件,然后该文件的内容将使用与playbook相同的语法将变量设置为值:

user: tom

​ 类似的,为了定义用于特定主机的主机变量,需要在host_vars目录中创建名称与主机匹配的文件来存放主机变量。

​ 下面的示例更加详细的说明了这一做法。例如在一个场景中,需要管理两个数据中心,并在 /etc/ansible/project 清单文件中定义数据中心主机:

[root@localhost ~]# mkdir /etc/ansible/project
[root@localhost ~]# vim /etc/ansible/project/inventory
[datacenter1]
node1.example.com
node2.example.com

[datacenter2]
node3.example.com
node4.example.com

[datacenters:children]
datacenter1
datacenter2

如果需要为两个数据中心的所有服务器定义一个通用值,可以为datacenters主机组设置一个组变量:

[root@localhost ansible]# mkdir group_vars
[root@localhost ansible]# vim /group_vars/datacenters
package: httpd

如果要为每个数据中心定义不同的值,可以为每个数据中心主机组设置组变量:

[root@localhost ansible]# vim groupo_vars/datacenter1
package: httpd
[root@localhost ~]# vim groupo_vars/datacenter2
package: mysql

如果要为每一数据中心的各个主机定义不同的值,则在单独的主机变量文件中定义变量:

[root@localhost ansible]# mkdir host_vars
[root@localhost ansible]# vim host_vars/node1.example.com
package: httpd
[root@localhost ansible]# vim host_vars/node2.example.com
package: apache2
[root@localhost ansible]# vim host_vars/node3.example.com
package: mariadb-server
[root@localhost ansible]# vim host_vars/node4.example.com
package: mysql-server

示例项目的目录结构如果包含上面所有示例文件:

[root@localhost ansible]# tree /etc/ansible
/etc/ansible
├── ansible.cfg
├── group_vars
│   ├── datacenters
│   ├── datacenters1
│   └── datecenters2
├── host_vars
│   ├── node1.example.com
│   ├── node2.example.com
│   ├── node3.example.com
│   └── node4.example.com
├── inventory
└── test.yml

2 directories, 10 files

使用数组做为变量

除了将同一元素相关的配置数据(软件包列表、服务列表和用户列表等)分配到多个变量外,也可以使用数组。这种做法的一个好处在于,数组是可以浏览的。

user1_first_name: tom
user1_last_name: jerry
user1_home_dir: /users/btom
user2_first_name: harry
user2_last_name: alis
user2_home_dir: /users/bharry

可以改写成名为users的数组:

users:
  btom:
    first_name: tom
    last_name: jerry
    home_dir: /users/btom
  bharry:
    first_name: harry
    last_name: alis
    home_dir: /users/bharry

然后可以使用以下变量来访问用户数据:

# Returns 'tom'
users.btom.first_name

# Returns '/users/bharry'
users.bharry.home_dir

由于变量被定义为Python字典,因此可以使用替代语法:

# Returns 'tom'
users['btom']['first_name']

# Returns '/users/bharry'
users['bharry']['home_dir']

如果键名与python方法或属性的名称(如discard、copy和add)相同,点表示法可能会造成问题。使用中括号表示法有助于避免冲突和错误。

但要声明的是,上面介绍的两种语法都有效,但为了方便故障排除,建议在任何给定Ansible项目的所有文件中一致地采用一种语法,不要混用。

从命令行覆盖变量

​ 清单变量可被playbook中设置的变量覆盖,这两种变量又可通过在命令行中传递参数到ansible或ansible-playbook命令来覆盖。在命令行上设置的变量称为额外变量。

当需要覆盖一次性运行的playbook的变量的已定义值时,额外变量非常有用。例如:

ansible-playbook test01.yml -e "package=httpd"

使用已注册变量捕获命令输出

​ 可以使用 **register **语句捕获命令输出。输出保存在一个临时变量中,然后在playbook中可用于调试用途或者达成其他目的,例如基于命令输出的特定配置。

示例:为调试用途捕获命令输出

[root@localhost ansible]# cat test.yml 
---
 - name: test
   hosts: 192.168.220.8
   gather_facts: no
   tasks:
      - name: install
        yum:
            name: httpd
            state: installed
        register: installed_result

      - debug: var=installed_result    # 安装结果

运行该playbook时,debug模块用于将install_result注册变量的值转储到终端。

[root@localhost ansible]# ansible-playbook test.yml 

PLAY [test] *************************************************************************************

TASK [install] **********************************************************************************
changed: [192.168.220.8]

TASK [debug] ************************************************************************************
ok: [192.168.220.8] => {
    "installed_result": {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/libexec/platform-python"
        },
        "changed": true,
        "failed": false,
        "msg": "",
        "rc": 0,
        "results": [
            "Installed: httpd-2.4.37-40.module_el8.5.0+852+0aafc63b.x86_64",
            "Installed: apr-1.6.3-11.el8.x86_64",
            "Installed: httpd-filesystem-2.4.37-40.module_el8.5.0+852+0aafc63b.noarch",
            "Installed: mailcap-2.1.48-3.el8.noarch",
            "Installed: apr-util-1.6.1-6.el8.x86_64",
            "Installed: apr-util-bdb-1.6.1-6.el8.x86_64",
            "Installed: httpd-tools-2.4.37-40.module_el8.5.0+852+0aafc63b.x86_64",
            "Installed: apr-util-openssl-1.6.1-6.el8.x86_64",
            "Installed: mod_http2-1.15.7-3.module_el8.4.0+778+c970deab.x86_64",
            "Installed: centos-logos-httpd-85.8-1.el8.noarch"
        ]
    }
}

PLAY RECAP **************************************************************************************
192.168.220.8              : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

机密简介

ansible vault

​ Ansible可能需要访问密码或API密钥等敏感数据,以便能配置受管主机。通常,此信息可能以纯文本形式存储在清单变量或其他Ansible文件中。但若如此,任何有权访问Ansible文件的用户或存储这些Ansible文件的版本控制系统都能够访问此敏感数据。存在安全风险。

​ Ansible提供的Ansible Vault可以加密和解密任何由Ansible使用的结构化数据文件。若要使用Ansible Vault,可通过一个名为ansible-vault的命令行工具创建、编辑、加密、解密和查看文件。Ansible Vault可以加密任何由Ansible使用的结构化数据文件。这可能包括清单变量、playbook中含有的变量文件、在执行playbook时作为参数传递的变量文件,或者Ansible角色中定义的变量。

创建加密文件

​ 创建新的加密文件,可使用 ansible-vault create filename 命令。该命令将提示输入新的vault密码,然后利用默认编辑器vi打开文件。我们可以设置和导出EDITOR环境变量,通过设置和导出指定其他默认编辑器。例如,若要将默认编辑器设为nano,可设置为export EDITOR=nano

[root@localhost ansible]# ansible-vault create gfdg.yml
New Vault password: 123
Confirm New Vault password: 123   #设置完密码后会自动打开vi编辑器

机密后查看该文件内容,是看不到里面的内容

[root@localhost ansible]# cat gfdg.yml
$ANSIBLE_VAULT;1.1;AES256
31393938386463613364343731643766313966313231343762623834303162366436656462643932
3262656664616462666532393838386136306134633863310a353261383465336662386332633366
61633834626163643436666230313932646164643966666236646565353132343262633738333061
3837353739346566310a626363313239326434313465383362353734313031616635633965393563
3431

还可以用vault密码文件来存储vault密码,而不是通过标准输入途径输入vault密码。这样做需要使用文件权限和其他方式来严密保护该文件。

ansible-vault create --vault-password-file=gfdg.yml hosts_vars/lll.yml
        # 将 gfdg.yml 里面的内容当作 hosts_vars/lll.yml 的密码

查看加密的文件

使用 ansible-vault view filename 命令查看Ansible Vault加密的文件,而不必打开它进行编辑。

查看时需要输入加密文件的加密密码。

[root@localhost ansible]# ansible-vault view gfdg.yml 
Vault password: 123 # 输入加密的密码 
password:123        # 里面的内容

编辑现有的机密文件

要编辑现有的加密文件,Ansible Vault提供了 ansible-vault edit filename 命令。此命令将文件解密为一个临时文件,并允许编辑。保存时,它将复制其内容并删除临时文件。

[root@localhost ansible]# ansible-vault edit gfdg.yml
Vault password: 123   # 输入密码后将自动打开vim编辑器

编辑时需要输入加密文件的加密密码。

edit 子命令始终重写文件,因此只应在进行更改时使用它。要查看文件的内容而不进行更改时,应使用 view 子命令。

加密现有的文件

要加密已存在的文件,请使用 ansible-vault encrypt filename 命令。此命令可取多个欲加密文件的名称作为参数。

[root@localhost ansible]# ansible-vault encrypt student.yml 
New Vault password: 123
Confirm New Vault password: 123
Encryption successful  # 加密成功

使用**–output=OUTPUT_FILE选项,可将加密文件保存为新的名称。只能通过–output**选项使用一个输入文件。

解密现有的文件

现有的加密文件可以通过ansible-vault decrypt filename命令永久解密。在解密单个文件时,可使用**–output**选项以其他名称保存解密的文件。

[root@localhost ansible]# ansible-vault decrypt student.yml # 解密
Vault password: 123
Decryption successful # 解密成功
[root@localhost ansible]# cat student.yml  # 查看文件内容
123

更改加密文件的密码

使用ansible-vault rekey filename命令更改加密文件的密码。此命令可一次性更新多个数据文件的密钥。它将提示提供原始密码和新密码。

[root@localhost ansible]# ansible-vault rekey student.yml
Vault password:             # 密码
New Vault password:         # 新的密码
Confirm New Vault password: # 再次输入新的密码
Rekey successful            # 更改成功

在使用vault密码文件时,请使用–new-vault-password-file选项:

[root@localhost ansible]# cat children 
12345678
[root@localhost ansible]# ansible-vault rekey --new-vault-password-file=children student.yml 
Vault password:     # 旧密码
Rekey successful    # 更改成功
# children文件里面写着新的密码,student.yml的新密码就更改成了children里面的新密码

运行加密的playbook文件

​ 要运行可访问通过Ansible Vault加密的文件的playbook,需要向ansible-playbook命令提供加密密码。如果不提供密码,playbook将返回错误:

[root@localhost ansible]# ansible-playbook student.yml 
ERROR! Attempting to decrypt but no vault secrets found

​ 要为playbook提供vault密码,可使用–vault-id选项。例如,要以交互方式提供vault密码,请使用下例中所示的–vault-id @prompt:

[root@localhost ansible]# ansible-playbook --vault-id @prompt student.yml 
Vault password (default):           # 输入正确密码后运行

也可以使用–vault-password-file选项指定以纯文本存储加密密码的文件。密码应当在该文件中存储为一行字符串。由于该文件包含敏感的纯文本密码,因此务必要通过文件权限和其他安全措施对其加以保护。

[root@localhost ansible]# cat gfdg.yml 
1234
[root@localhost ansible]# ansible-playbook --vault-password-file=gfdg.yml student.yml                                                               # gfdg.yml文件里写着student.yml文件的密码,完成后将运行student.yml文件

也可以使用ANSIBLE_VAULT_PASSWORD_FILE环境变量,指定密码文件的默认位置。

从Ansible2.4开始,可以通过ansible-playbook使用多个Ansible Vault密码。要使用多个密码,需要将多个**–vault-id–vault-password-file选项传递给ansible-playbook**命令。

ansible-playbook --vault-id one@prompt --vault-id two@prompt site.yml

注意:@prompt前面的vaultIDonetwo可以是任何字符,甚至可以完全省略它们。不过,如果在使用ansible-vault命令加密文件时使用**–vault-id id选项,则在运行ansible-playbook时,将最先尝试匹配ID的密码。如果不匹配,将会尝试用户提供的其他密码。没有ID的vaultID@prompt实际上是default@prompt的简写,这意味着提示输入vaultIDdefault**的密码。

管理变量文件的推荐做法

若要简化管理,务必要设置Ansible项目,使敏感变量和其他变量保存在相互独立的文件中。然后,包含敏感变量的文件可通过ansible-vault命令进行保护。

管理组变量和主机变量的首选方式是在playbook级别上创建目录。group_vars目录通常包含名称与它们所应用的主机组匹配的变量文件。host_vars目录通常包含名称与它们所应用的受管主机名称匹配的变量文件。

不过,除了使用group_vars和host_vars中的文件外,也可对每一主机组或受管主机使用目录。这些目录可包含多个变量文件,它们都由该主机组或受管主机使用。例如,在playbook.yml的以下项目目录中,webservers的主机组的成员将使用group_vars/webservers/vars文件中的变量,而192.168.220.8将使用host_vars/192.168.220.8/vars和host_vars/192.168.220.8/vault中的变量:

─ ansible.cfg
├── group_vars
│   └── webservers
│       └── vars
├── host_vars
│   └── 192.168.220.8
│       ├── vars
│       └── vault
├── inventory
└── playbook.yml

​ 在这种情况中,其好处在于用于192.168.220.8的大部分变量可以放在vars文件中,敏感变量则可单独放在vault文件中保密。然后使用ansible-vault加密vault文件,而将vars文件保留为纯文本。

​ 在本例中,host_vars/192.168.220.8目录内使用的文件名没有什么特别之处。该目录可以包含更多文件,一些由Ansible Vault加密,另一些则不加密。

Playbook变量(与清单变量相对)也可通过Ansible Vault保护。敏感的playbook变量可以放在单独的文件中,此文件通过Ansible Vault加密,并能vars_files指令包含在该playbook中。这也是推荐做法,因为playbook变量的优先级高于清单变量。

如果需要在playbook中使用多个vault密码,请确保每个加密文件分配一个vaultID,并在运行playbook时输入具有该vaultID的匹配密码。这可确保在解密vault加密文件时先选择正确的密码,这比强制Ansible尝试用户提供的所有vault密码直至找到正确的密码要快。

事实

事实简介

​ 事实是Ansible在受管主机上自动检测到的变量。事实中包含有与主机相关的信息,可以像play中的常规变量、条件、循环或依赖于从受管主机收集的值的任何其他语句那样使用。

为受管主机收集的一些事实可能包括:

  • IP地址

  • 主机名称

  • 网络接口

  • CPU数量

  • 内核版本

  • 可用磁盘空间

  • 各种环境变量

  • 操作系统版本

  • 提供的或可用的内存内核版本

**借助事实,可以方便地检索受管主机的状态,并根据该状态确定要执行的操作。**例如:

  • 可以根据含有受管主机当前内核版本的事实运行条件任务,以此来重启服务器
  • 可以根据通过事实报告的可用内存来自定义MySQL配置文件
  • 可以根据事实的值设置配置文件中使用的IPv4地址

通常,每个play在执行第一个任务之前会先自动运行setup模块来收集事实。

查看为受管主机收集的事实的一种方式是,运行一个收集事实并使用debug模块显示ansible_facts变量值的简短playbook。

---
 - name: test
   hosts: "*"
   tasks:          # 任务
     - name: print all facts   # 打印所有的事实
       debug:
          var: ansible_facts 

playbook 以 JSON 格式显示 ansible_facts 变量的内容。

运行该playbook时,事实将显示在输出:

[root@localhost ansible]# ansible-playbook setup 

PLAY [test] *******************************************************************************************

TASK [Gathering Facts] ********************************************************************************
ok: [192.168.220.8]

TASK [print all facts] ********************************************************************************
ok: [192.168.220.8] => {
    "ansible_facts": {
        "all_ipv4_addresses": [
            "192.168.220.8"
        ],
......

下面显示了可能从受管节点收集的并可在playbook中使用的一些事实:

事实 变量
短主机名 ansible_facts[‘hostname’]
完全限定域名 ansible_facts[‘fqdn’]
IPv4地址 ansible_facts[‘default_ipv4’][‘address’]
所有网络接口的名称列表 ansible_facts[‘interfaces’]
/dev/vda1磁盘分区的大小 ansible_facts[‘devices’][‘vda’][‘partitions’][‘vda1’][‘size’]
DNS服务器列表 ansible_facts[‘dns’][‘nameservers’]
当前运行的内核版本 ansible_facts[‘kernel’]
---
 - name: test
   hosts: "*"
   tasks:
     - name: print facts
       debug:
          var: ansible_facts['hostname']       # 获取事实的短主机名

[root@localhost ansible]# ansible-playbook setup 
......
TASK [print facts] ************************************************************************************
ok: [192.168.220.8] => {
    "ansible_facts['hostname']": "localhost"  # 结果
}
......
---
 - name: test
   hosts: "*"
   tasks:
     - name: print facts
       debug:
          var: ansible_facts['fqdn']             # 获取事实的完全限定域名
[root@localhost ansible]# ansible-playbook setup 
.....
TASK [print facts] ************************************************************************************
ok: [192.168.220.8] => {
    "ansible_facts['fqdn']": "localhost.localdomain"   # 结果
}
......

如果变量的值为散列/字典类型,则可使用两种语法来获取其值。比如:

  • ansible_facts[‘default_ipv4’][‘address’]也可以写成ansible_facts.default_ipv4.address
  • ansible_facts[‘dns’][‘nameservers’]也可以写成ansible_facts.dns.nameservers

在playbook中使用事实时,Ansible将事实的变量名动态替换为对应的值:

---
 - name: test
   hosts: "*"
   tasks:
     - name: print facts
       debug:
         msg: >
           The default ipv4 address of {{ ansible_facts['default_ipv4']['address'] }} 
           is {{ ansible_facts['dns']['nameservers'] }}
         
[root@localhost ansible]# ansible-playbook setup   # 运行
.....
TASK [print facts] ************************************************************************************
ok: [192.168.220.8] => {
    "msg": "The default ipv4 address of 192.168.220.8  is ['114.114.114.114']\n"   # 打印默认IP和DNS
}
.....

将事实作为变量注入

​ 在Ansible2.5之前,事实是作为前缀为字符串ansible_的单个变量注入,而不是作为ansible_facts变量的一部分注入。例如,ansible_facts[‘distribution’]事实会被称为ansible_distribution。

许多较旧的playbook仍然使用作为变量注入的事实,而不是在ansible_facts变量下创建命名空间的新语法。我们可以使用临时命令来运行setup模块,以此形式显示所有事实的值。以下示例中使用一个临时命令在受管主机192.168.220.8上运行setup模块:

ansible 192.168.220.8 -m setup

选定的Ansible事实名称比较

ansible_facts形式 旧事实变量形式
ansible_facts[‘hostname’] ansible_hostname
ansible_facts[‘fqdn’] ansible_fqdn
ansible_facts[‘default_ipv4’][‘address’] ansible_default_ipv4[‘address’]
ansible_facts[‘interfaces’] ansible_interfaces
ansible_facts[‘devices’][‘vda’][‘partitions’][‘vda1’][‘size’] ansible_devices[‘vda’][‘partitions’][‘vda1’][‘size’]
ansible_facts[‘dns’][‘nameservers’] ansible_dns[‘nameservers’]
ansible_facts[‘kernel’] ansible_kernel

目前,Ansible同时识别新的事实命名系统(使用ansible_facts)和旧的2.5前“作为单独变量注入的事实”命名系统。

将Ansible配置文件的**[default]部分中inject_facts_as_vars参数设置为False**,可关闭旧命名系统。默认设置目前为True

[root@localhost ansible]# vim ansible.cfg 
65 # ansible_facts.
66 inject_facts_as_vars = false  # 默认为True,改为false,去掉行首的'#'就不支持旧命名系统了

---
 - name: test
   hosts: "*"
   tasks:
     - name: print facts
       debug:
         var: ansible_hostname  #  旧的事实变量形式 
[root@localhost ansible]# ansible-playbook setup  # 执行
.....
TASK [print facts] ************************************************************************************
ok: [192.168.220.8] => {
    "ansible_hostname": "VARIABLE IS NOT DEFINED!"  # 变量未定义 失败了
}
....

inject_facts_as_vars的默认值在Ansible的未来版本中可能会更改为False。如果设置为False,则只能使用新的**ansible_facts.***命名系统引用Ansible事实。所以建议大家一开始就要适应这种方式。

关闭事实收集

有时我们不想为play收集事实。这样做的原因可能有:

  • 希望加快play速度
  • 不准备使用任何事实
  • 需要安装一些必备软件后再收集事实
  • 希望减小play在受管主机上造成的负载
  • 受管主机因为某种原因无法运行setup模块

以上种种原因导致我们可能想要永久或暂时关闭事实收集的功能,要为play禁用事实收集功能,可将gather_facts关键字设置为no:

---
 - name: test
   hosts: "*"
   gather_facts: on    # 设置为on,关闭事实收集功能
   tasks:

即使play设置了gather_facts: no,也可以随时通过运行使用setup模块的任务来手动收集事实:

---
- name: gather_facts
  hosts: 172.16.103.129
  gather_facts: no
  tasks:
    - name: get gather_facts
      setup:                # 通过运行使用setup模块的任务来手动收集事实
    - name: use debug
      debug:
        var: ansible_facts

创建自定义事实

​ 除了使用系统捕获的事实外,我们还可以自定义事实,并将其本地存储在每个受管主机上。这些事实整合到setup模块在受管主机上运行时收集的标准事实列表中。它们让受管主机能够向Ansible提供任意变量,以用于调整play的行为。

​ 自定义事实可以在静态文件中定义,格式可为INI文件或采用JSON。它们也可以是生成JSON输出的可执行脚本,如同动态清单脚本一样。

​ 有了自定义事实,我们可以为受管主机定义特定的值,供play用于填充配置文件或有条件地运行任务。动态自定义事实允许在play运行时以编程方式确定这些事实的值,甚至还可以确定提供哪些事实。

​ 默认情况下,setup模块从各受管主机的/etc/ansible/facts.d目录下的文件和脚本中加载自定义事实。各个文件或脚本的名称必须以**.fact**结尾才能被使用。动态自定义事实脚本必须输出JSON格式的事实,而且必须是可执行文件。

​ 以下是采用INI格式编写的静态自定义事实文件。INI格式的自定义事实文件包含由一个部分定义的顶层值,后跟用于待定义的事实的键值对:

root@localhost ~]# mkdir /etc/ansible -p   # 在受管主机创建/etc/ansible
[root@localhost ~]# cd /etc/ansible/
[root@localhost ansible]# mkdir facts.d
[root@localhost ansible]# cd facts.d/
[root@localhost facts.d]# vi facts.fact
[packages]
svr_package = apache
ss_package = php

[users]
user1 = tom
user2 = harry

[root@localhost facts.d]# tree /etc/ansible/  # 查看一下结构
/etc/ansible/
`-- facts.d
    `-- facts.fact
    
    
[root@localhost ansible]# ansible all -m setup |less  # 在ansible控制机上执行
.....
 "ansible_local": {
            "facts": {
                "packages": {
                    "ss_package": "php",     # 创建的自定义事实
                    "svr_package": "apache"
                },
                "users": {
                    "user1": "tom",
                    "user2": "harry"
.....        

​ 同样的事实可能以JSON格式提供。以下JSON事实等同于以上示例中INI格式指定的事实。JSON数据可以存储在静态文本文件中,或者通过可执行脚本输出到标准输出:

"ansible_local": {
    "facts": {
      "packages": {
           "ss_package": "php",
           "svr_package": "apache"
                },
        "users": {
           "user1": "tom",
           "user2": "harry"
        }
     }
  }

​ 自定义事实文件不能采用playbook那样的YAML格式。JSON格式是最为接近的等效格式。

​ 自定义事实由setup模块存储在ansible_facts.ansible_local变量中。
事实按照定义它们的文件的名称来整理。例如,假设前面的自定义事实由受管主机上保存为**/etc/ansible/facts.d/custom.fact**的文件生成。在这种情况下,ansible_facts.ansible_local[‘custom’][‘users’][‘user1’]的值为joe

​ 可以利用临时命令在受管主机上运行setup模块来检查自定义事实的结构。

ansible 192.168.220.8 -m setup

​ 自定义事实的使用方式与playbook中的默认事实相同:

---
- hosts: all
  tasks:
  - name: Prints various Ansible facts
    debug:
      msg: >
        The package to install on {{ ansible_facts['fqdn'] }}
        is {{ ansible_facts['ansible_local']['cutstom']['packages']['web_package'] }}

魔法变量

一些变量并非事实或通过setup模块配置,但也由Ansible自动设置。这些魔法变量也可用于获取与特定受管主机相关的信息。

最常用的有四个:

魔法变量 说明
hostvars 包含受管主机的变量,可以用于获取另一台受管主机的变量的值。 如果还没有为受管主机收集事实,则它不会包含该主机的事实。
group_names 列出当前受管主机所属的所有组
groups 列出清单中的所有组和主机
inventory_hostname 包含清单中配置的当前受管主机的主机名称。 因为各种原因有可能与事实报告的主机名称不同

另外还有许多其他的“魔法变量”。有关更多信息,请参见以下链接:
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable。
若要深入了解它们的值,一个途径是使用debug模块报告特定主机的hostvars变量的内容:

ansible 192.168.220.8 -m debug -a 'var=hostvars["localhost"]'
上一篇:ansible四


下一篇:ansible-playbook批量部署ELFK集群