一文解析 Ansible 配置管理文件

Posted 2022-10-02

本文将介绍Ansible项目配置管理部分，配置文件为ansible.cfg。

首先，本例中ansible.cfg的存储路径为/hoem/feng/ansible.cfg，即位于当前Ansible项目目录中。这样做的好处如下：

1）ansible.cfg的配置只对当前项目有效，在实际使用时，你可以根据自己的使用习惯进行私人定制。

2）当前目录下的ansible.cfg文件与Ansible全局文件（/etc/ansible/ansible.cfg）、其他Ansible项目中的ansible.cfg都不会冲突。Ansible读取配置文件的优先级由高到低依次为：ANSIBLE_CONFIG（系统环境变量）、ansible.cfg（位于当前目录中）、.ansible.cfg（位于家目录中）、/etc/ansible/ansible.cfg。

关于ansible.cfg文件的使用，有以下几条建议：

1）依据anisble.cfg最佳实践，准备一份通用版ansible.cfg文件并将其作为模板。

2）在Ansible项目目录中先复制通用版的ansible.cfg。

3）根据具体项目在通用版ansible.cfg的基础上进行定制，不必一开始就准备一份大而全的配置文件，可以在项目调试过程中根据需求随时动态添加相关内容。

接下来使用ansible-config命令行工具查看ansible.cfg文件中使用的配置项：

[root@ansible feng]#ansible-config view
[defaults]
inventory = ./xlsx_inventory.py
library = ./library
roles_path = ./roles

module_name = command
gathering = explicit
callback_enabled = timer

string_conversion_action = ignore
allow_world_readable_tmpfiles=True

command_warning = False
Host_key_checking = false
retry_files_enabled = false
deprecation_warnings = False

上述代码所示是一个常用的ansible.cfg模板，如果使用的不是动态inventory，可以将xlsx_inventory.py改成自己的inventory文件名字。下面对该文件中涉及的配置进行详细介绍。

1. inventory = ./xlsx_inventory.py这条配置的作用是定义Ansible默认查找ansible inventory文件的位置。如果没有添加这条配置，则Ansible会默认使用按照优先级顺序找到的第一个inventory文件，如果不打算使用默认inventory文件，则需要在使用Ansible命令时显式指定inventory文件的路径：

[root@ansible feng]#ansible all -i xlsx_inventory.py -m ping

添加下面这条配置后再执行Ansible命令时，就可以省略-i xlsx_inventory.py选项了：

[root@ansible feng]#ansible all -m ping

2. library = ./library这条配置的作用是定义Ansible自定义模块的存放目录。如果没有这条配置，自定义模块的目录名只能为library，且为当前Ansible项目目录，这是Ansible语法约定的。使用这条配置后，则可以将目录名改成任意名字，存放在任意指定位置。
3. roles_path = ./roles这条配置的作用是定义Ansible Roles的存放目录。如果没有这条配置，Ansible Roles的目录名只能为roles，且为当前Ansible项目目录，这是Ansible语法约定的。使用这条配置后，则可以将目录名改成任意名字，存放在任意指定位置。
4. module_name = command这条配置的作用是定义使用Ansible命令行工具时默认使用的Ansible模块。使用Ansible命令不加-m选项，则Ansible默认使用这条配置设定的模块，系统默认值为command，大家可以根据自己的使用习惯进行配置。

有些用户喜欢将Ansible命令行默认使用的模块由command换成shell，因为他们认为shell比command适用性广，在使用shell模块时，参数项可以直接使用所有的Linux shell命令，无论shell命令中是否包含管道符（|），但是Ansible默认使用的command模块更贴合Ansible的功能特性。

Ansible默认选择command模块而非shell的原因是command不通过系统的shell运行，因此使用command执行tasks时，执行结果不会受到被管主机用户环境的影响，相对更安全。正因为如此，用户特定的环境变量（如$HOME）无法通过command使用，类似的还有一些流操作（stream operation），如<、>、|、&等也无法使用。所以，如果需要使用被管主机的用户环境变量、命令或需要用到流操作时，那么只能选shell，其他情况建议一律选command。

5. gathering = explicit这条配置的作用是定义gather_facts的使用模式。gather_facts有3种使用模式，即implicit、explicit、smart，默认是implicit模式。3种使用模式的作用如下。

• implicit模式：这种模式下gather_facts默认开启，且禁用fact cache。如果想关闭gather_facts，需要在Playbook中显式指定gather_facts = False。
• explicit模式：这种模式下gather_facts默认关闭，且启用fact cache。如果想开启gather_facts，则需要在Playbook中显式指定gather_facts = True。
• smart模式：这种模式下gather_facts默认开启，且启用fact cache。这种模式与implicit模式的不同点在于，前者在Playbook运行过程中，每个主机的fact信息只采集一次。

如果需要禁用gather_facts的任务远多于需要启用gather_facts的任务，且大多数情况下编写Playbook时都会在play的配置选项里加上一条gather_facts = False，那么建议选用explicit模式。

默认情况下Ansible采集fact信息的时间开销还是很可观的，任务量少的时候尤为明显。如果想要优化这部分的时间开销，除了使用explicit模式外，还可使用gather_subset配置项。这个配置项可以与implicit模式配合使用，从而做到在启用gather_facts的同时又降低采集fact信息的时间开销。

6. callback_enabled = timer这条配置的作用是统计每个play的执行时间。在实际使用Ansible的过程中，如果遇到Playbook执行速度慢，想要查找耗时较多的play，来有针对性地优化Ansible的执行时间时，这条配置会很有帮助。
7. string_conversion_action = ignore这条配置的作用是处理Ansible模块传参时的类型转换模式。Ansible Playbooks在模块传参的时候，会默认将非string类型的数据强制转换成string类型，这个功能会在需要传list或dict等类型的参数时出现问题，并且抛出如下警告。使用string_conversion_action参数可以解决这个强制转换并报警的问题。
8. allow_world_readable_tmpfiles = True这条配置的作用是将在被管理端生成的临时目录设为全局可读，适用于become_user为非root且未提权的用户场景。
9. 4个常用的配置项

4个常用的配置项为command_warnings、host_key_checking、retry_files_enabled和deprecation_warnings，分别代表命令行错误警告、首次连接被管主机时的SSH key检查、执行失败时自动生成retry文件、版本遗弃功能警告。这几个配置项通常均默认设置为false。