6.10. 扫描作业模板
从自动化控制器 3.2 开始,不再支持扫描作业。此系统跟踪功能用作捕获和存储事实作为历史数据的方法。现在,事实通过事实缓存存储在控制器中。如需更多信息,请参阅 事实缓存。
在自动化控制器 3.2 之前,系统中的作业模板扫描作业将转换为运行类型,如正常的作业模板。它们保留其相关资源,如清单和凭证。默认情况下,没有相关项目的作业模板扫描作业会被分配一个特殊的 playbook。您还可以使用自己的扫描 playbook 指定项目。为每个指向 awx-facts-playbooks 的机构创建一个项目,并将作业模板设置为 playbook: https://github.com/ansible/tower-fact-modules/blob/master/scan_facts.yml。
6.10.1. 事实扫描 playbook
扫描作业 playbook scan_facts.yml
包含三种 事实扫描模块
(软件包、服务和文件)的调用,以及 Ansible 的标准事实收集。scan_facts.yml
playbook 文件类似如下:
- hosts: all vars: scan_use_checksum: false scan_use_recursive: false tasks: - scan_packages: - scan_services: - scan_files: paths: '{{ scan_file_paths }}' get_checksum: '{{ scan_use_checksum }}' recursive: '{{ scan_use_recursive }}' when: scan_file_paths is defined
scan_files
事实模块是唯一接受参数的模块,通过扫描作业模板上的 extra_vars
传递:
scan_file_paths
:/tmp/
scan_use_checksum
: true scan_use_recursive
: true
-
scan_file_paths
参数可以有多个设置(如/tmp/
或/var/log
)。 -
scan_use_checksum
和scan_use_recursive
参数也可以设置为 false 或省略。省略与 false 设置相同。
扫描作业模板应启用 become
,并使用 成为可能
的凭证
。您可以通过从选项列表中检查 Privilege Escalation 来启用 become
:
6.10.2. 支持的 scan_facts.yml OS
如果您使用带有使用事实缓存的 scan_facts.yml
playbook,请确保使用以下支持的操作系统之一:
- Red Hat Enterprise Linux 5、6、7、8 和 9
- Ubuntu 23.04 (支持 Ubuntu 已被弃用,将在以后的版本中删除)
- OEL 6 和 7
- SLES 11 和 12
- Debian 6、7、9、10、11 和 12
- Fedora 22、23 和 24
- Amazon Linux 2023.1.20230912
其中一些操作系统需要初始配置来运行 python,或者有权访问 python 软件包,如 python-apt
,扫描模块依赖。
6.10.3. 预扫描设置
以下是配置某些发行版本的 playbook 示例,以便可以针对它们运行扫描作业:
Bootstrap Ubuntu (16.04) --- - name: Get Ubuntu 16, and on ready hosts: all sudo: yes gather_facts: no tasks: - name: install python-simplejson raw: sudo apt-get -y update raw: sudo apt-get -y install python-simplejson raw: sudo apt-get install python-apt Bootstrap Fedora (23, 24) --- - name: Get Fedora ready hosts: all sudo: yes gather_facts: no tasks: - name: install python-simplejson raw: sudo dnf -y update raw: sudo dnf -y install python-simplejson raw: sudo dnf -y install rpm-python
6.10.4. 自定义事实扫描
自定义事实扫描的 playbook 与 Fact 扫描 playbook 部分中的示例类似。例如,只使用自定义 scan_foo
Ansible 事实模块的 playbook 类似如下:
scan_foo.py: def main(): module = AnsibleModule( argument_spec = dict()) foo = [ { "hello": "world" }, { "foo": "bar" } ] results = dict(ansible_facts=dict(foo=foo)) module.exit_json(**results) main()
要使用自定义事实模块,请确保它位于扫描作业模板中使用的 Ansible 项目的 /library/
子目录中。这个事实扫描模块返回一组硬编码的事实:
[ { "hello": "world" }, { "foo": "bar" } ]
有关更多信息,请参阅 Ansible 文档中的 开发模块 部分。
6.10.5. 事实缓存
自动化控制器可以通过 Ansible 事实缓存插件来基于每个主机存储和检索事实。这个行为可根据每个作业模板进行配置。默认情况下,事实缓存会被关闭,但可以启用来为与作业运行相关的清单中所有主机提供事实请求。这可让您使用带有- limit
的作业模板,同时仍可访问整个主机事实清单。您可以在导航面板中指定插件强制按主机(以秒为单位)的全局超时设置,选择
在启动使用事实缓存(use_fact_cache=True
的作业后,每个主机的 ansible_facts
均由控制器存储在作业的清单中。
包含自动化控制器的 Ansible 事实缓存插件在启用了事实缓存的作业上启用(use_fact_cache=True
)。
当一个启用了事实缓存(use_fact_cache=True
)的作业正在运行时,自动化控制器会恢复清单中主机的所有记录。任何比每个主机当前存储事实更新时间更新的记录都会在数据库中更新。
新的和更改的事实通过自动化控制器的日志记录功能记录。特别是 system_tracking 命名空间或日志记录
器。日志记录有效负载包括以下字段:
-
host_name
-
inventory_id
-
ansible_facts
Ansible 事实是自动化控制器清单 inventory_id
中 host_name
的所有 Ansible 事实的字典。
如果主机名包含正斜杠(/),事实缓存不适用于该主机。如果您的清单有 100 个主机,且一个主机的名称中有一个 /,则剩余的 99 个主机仍然收集事实。
6.10.6. 事实缓存的好处
事实缓存可让您通过运行事实收集来节省时间。如果您在某个作业中有一个针对一千个主机和分叉运行的 playbook,您可以花费 10 分钟在所有这些主机上收集事实。但是,如果您定期运行作业,第一次运行会缓存这些事实,下一次运行会从数据库中拉取它们。这可减少针对大型清单(包括智能清单)的作业运行时。
不要更改 ansible.cfg 文件以应用事实缓存。自定义事实缓存可能会与控制器的事实缓存功能冲突。您必须使用包含自动化控制器的事实缓存模块。
您可以选择在创建或编辑作业模板时检查 Enable fact 存储 选项来在作业中使用缓存的事实。
若要清除事实,请运行 Ansible clear_facts
meta 任务。以下是使用 Ansible clear_facts
meta 任务的示例 playbook。
- hosts: all gather_facts: false tasks: - name: Clear gathered facts from all currently targeted hosts meta: clear_facts
您可以在以下找到事实缓存的 API 端点:
http://<controller server name>/api/v2/hosts/x/ansible_facts