19. 作业模板

自动化控制器可以通过 Ansible 事实缓存插件按主机存储和检索事实。此行为可以按作业模板进行配置。事实缓存默认关闭，但可以启用以满足与作业运行相关的清单中所有主机的事实请求。这可让您将作业模板与 --limit 搭配使用，同时仍可访问整个主机事实清单。插件按主机强制应用的全局超时设置可在 Jobs 设置菜单中指定（以秒为单位）：

在启动使用事实缓存（use_fact_cache=True）的作业后，控制器会保存与作业关联的清单中的每个主机所关联的所有 ansible_facts。automation controller 附带的 Ansible 事实缓存插件只会在启用了事实缓存（use_fact_cache=True）的作业上启用。

当启用事实缓存（use_fact_cache=True）的作业完成运行时，控制器将恢复清单中主机的所有记录。任何更新时间比每个主机当前存储的事实“更新”的记录都会在数据库中更新。

新事实和更改的事实将通过控制器的日志记录功能记录，具体来说是记录到 system_tracking 命名空间或日志记录器。日志记录有效负载将包括以下字段：

host_name

inventory_id

ansible_facts

其中 ansible_facts 是控制器清单 inventory_id 中 host_name 的所有 Ansible 事实的字典。

注解

如果主机名包含正斜杠 (/)，事实缓存将不适用于该主机。如果清单中有 100 个主机，其中一个主机的名称中有一个 /，其中的 99 个主机仍会收集事实。

相较于运行事实收集，事实缓存会节省大量时间。如果您在一个针对一千个主机和 fork 运行的作业中有一个 playbook，您可以轻松地花 10 分钟来收集所有这些主机的事实。但是如果您定期运行一个作业，第一次运行会缓存这些事实，而下一次运行只需从数据库中拉取它们。这会大幅削减针对大型清单（包括智能清单）的作业运行时间。

注解

不要修改 ansible.cfg 文件来应用事实缓存。自定义事实缓存可能会与 控制器的事实缓存功能冲突。我们推荐使用 automation controller 附带的事实缓存模块。隔离的节点不支持事实缓存。

您可以选择在作业模板窗口的 Options 字段中启用缓存的事实以在作业中使用它。

要清除事实，您需要运行 Ansible clear_facts meta task。以下是使用 Ansible clear_facts 元任务的示例 playbook。

事实缓存的 API 端点可以在以下网站找到：http:///api/v2/hosts/x/ansible_facts。

云凭证可以在同步相应的云清单时使用。云凭证还可能与作业模板关联，并包含在运行时环境中，供 playbook 使用。当前支持的云凭证：

以下示例 playbook 调用 nova_compute Ansible OpenStack 云模块，并要求凭证进行任何有意义的操作，它要求提供以下信息：auth_url、username、password 和 project_name。这些字段通过环境变量 OS_CLIENT_CONFIG_FILE 提供给 playbook，此变量指向控制器根据云凭证的内容编写的 YAML 文件。此示例 playbook 会将 YAML 文件加载到 Ansible 变量空间中。

OS_CLIENT_CONFIG_FILE 示例：

Playbook 示例：

Amazon Web Services 云凭证在 playbook 执行过程中作为以下环境变量公开（在作业模板中，选择您的设置所需的云凭证）：

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

所有 AWS 模块在通过控制器运行时都会隐式使用这些凭证，而无需设置 aws_access_key_id 或 aws_secret_access_key 模块选项。

Google 云凭证在 playbook 执行过程中作为以下环境变量公开（在作业模板中，选择您的设置所需的云凭证）：

GCE_EMAIL

GCE_PROJECT

GCE_CREDENTIALS_FILE_PATH

所有 Google 模块在通过控制器运行时都会隐式使用这些凭证，而无需设置 service_account_email、project_id 或 pem_file 模块选项。

Azure 云凭证在 playbook 执行过程中作为以下环境变量公开（在作业模板中，选择您的设置所需的云凭证）：

AZURE_SUBSCRIPTION_ID

AZURE_CERT_PATH

所有 Azure 模块在通过控制器运行时都会隐式使用这些凭证，而无需设置 subscription_id 或 management_cert_path 模块选项。

VMware 云凭证在 playbook 执行过程中作为以下环境变量公开（在作业模板中，选择您的设置所需的云凭证）：

VMWARE_USER

VMWARE_PASSWORD

VMWARE_HOST

以下示例 playbook 演示了这些凭证的使用情况：

置备回调是自动化控制器的一项功能，允许主机启动针对自身运行的 playbook，而不是等待用户启动作业以从自动化控制器控制台管理主机。请注意，置备回调*仅*用于在调用主机上运行 playbook。置备回调用于云爆发，即：需要客户端到服务器通信以进行配置（例如传输授权密钥）的新实例，而不是针对另一台主机运行作业。这就为以下操作提供了条件：当一个系统通过另一个系统（例如 AWS 自动缩放或操作系统置备系统，如 kickstart 或 preseed）进行配置后，会自动配置该系统；或者通过编程方式启动作业，而无需直接调用自动化控制器 API。启动的作业模板仅针对请求配置的主机运行。

通常这会通过 firstboot 类型脚本或从 cron 访问。

要启用回调，请选中作业模板中的 Provisioning Callbacks 复选框。这会显示此作业模板的 Provisioning Callback URL。

注解

如果要将自动化控制器的置备回调功能与动态清单结合使用，则应该为作业模板中使用的清单组设置在启动时更新。

回调还需要一个主机配置密钥，以确保具有 URL 的外部主机无法请求配置。请为主机配置密钥提供一个自定义值。主机密钥可在多个主机间重复使用，以针对多个主机应用此作业模板。如果您希望控制哪些主机可以请求配置，则可以随时更改该密钥。

要通过 REST 手动回调，请查看 UI 中的回调 URL，其格式为：

这个示例 URL 中的“7”是自动化控制器中的作业模板 ID。

来自主机的请求必须是 POST。以下是一个使用 curl 的示例（全部在一行）：

发出请求的主机必须在您的清单中定义，才能使回调成功。如果自动化控制器无法按名称或 IP 地址在您定义的某一个清单中找到主机，则请求将被拒绝。在以这种方式运行作业模板时，启动针对其自身运行的 playbook 的主机必须位于清单中。如果该主机不在清单中，则作业模板将失败，并显示“No Hosts Matched”类型错误消息。

注解

如果您的主机不在清单中，并且为清单组设置了 Update on Launch，则自动化控制器会在运行回调前尝试更新基于云的清单源。

成功请求会在 Jobs 标签页中生成一个条目，可以在其中查看结果和历史记录。

虽然可以通过 REST 访问回调，但建议的回调使用方法是使用自动化控制器附带的示例脚本之一 - /usr/share/awx/request_tower_configuration.sh (Linux/UNIX) 或 /usr/share/awx/request_tower_configuration.ps1 (Windows)。用法在文件的源代码中通过传递 -h 标签进行描述，如下所示：

这个脚本非常智能，因为它知道如何重试命令，因此比起简单的 curl 请求，它是更强大的回调使用方法。正如所编写的，脚本每分钟重试一次，最多十分钟。

注解

请注意，这是一个示例脚本。如果您在检测到失败情况时需要更多的动态行为，应编辑这个脚本，因为任何非 200 的错误代码都可能不是需要重试的暂时性错误。

您最有可能在自动化控制器中将回调与动态清单搭配使用，如从支持的某个云提供商中拉取云清单。在这些情况下，除了设置 Update On Launch 以外，请务必为清单源配置清单缓存超时，以避免云的 API 端点受到攻击。由于 request_tower_configuration.sh 脚本每分钟轮询一次，最多十分钟，因此推荐的清单缓存失效时间（在清单源本身中配置）将为一分钟或两分钟。

虽然我们不推荐从 cron 作业运行 request_tower_configuration.sh 脚本，但建议的 cron 间隔可能为每 30 分钟。重复的配置可以通过在自动化控制器中调度来轻松处理，因此大多数用户主要使用回调来启用一个在上线时引导至最新配置的基础镜像。为此，在第一次引导时运行是更好的做法。初始引导脚本只是简单的 init 脚本，通常会自我删除，因此您可以设置一个调用 request_tower_configuration.sh 脚本副本的 init 脚本，并使之成为一个自动缩放镜像。

就像您可以在常规作业模板中传递 extra_vars 一样，您也可以将它们传递到配置回调。要传递 extra_vars，发送的数据必须作为应用程序/json（作为内容类型）成为 POST 请求主体的一部分。在添加您自己的 extra_vars 进行传递时，请使用以下 JSON 格式作为示例：

您还可以使用 curl 将额外变量传递给作业模板调用，如以下示例所示：

有关详情请参阅 Launching Jobs with Curl。

注解

只有在以下条件之一被满足时，传递给作业启动 API 的 extra_vars 才有效：

它们与启用的问卷调查（survey）中的变量对应

ask_variables_on_launch 被设为 True

当您传递问卷调查变量时，它们作为控制器中的额外变量 (extra_vars) 传递。这样做可能需要非常小心，因为将额外变量传递给作业模板（就像对问卷调查的操作一样）可能会覆盖从清单和项目传递的其他变量。

例如，假设您为清单定义了一个变量 debug = true。在作业模板问卷调查中完全有可能覆盖 debug = true 这个变量。

为确保不覆盖您需要传递的变量，请通过在问卷调查中重新定义变量来确保将其包括在内。请记住，可以在清单、组和主机级别定义额外的变量。

如果指定 ALLOW_JINJA_IN_EXTRA_VARS 参数，请参阅 Automation Controller Administration Guide 的 Controller Tips and Tricks 部分，以便在控制器 UI 的 Jobs Settings 屏幕中进行配置。

注解

作业模板额外变量字典与 Survey 变量合并。

以下是 YAML 和 JSON 格式的 extra_vars 的一些简化示例：

YAML 格式的配置：

JSON 格式的配置：

下表记录了 automation controller 中的变量优先级的行为（层次结构）与 Ansible 中的变量优先级比较情况。

自动化控制器变量优先级层次结构（最后列出的优先）

重新启动通过将 launch_type 设置为 relaunch 来表示，而不是手动重新启动作业。重新启动行为与启动行为的偏差在于它**不**继承 extra_vars。

作业重新启动不会通过继承逻辑。它会使用为重新启动的作业计算的相同 extra_vars。

例如，假设您启动一个没有 extra_vars 的作业模板，导致创建一个名为 j1 的作业。下一步，假设您编辑作业模板，并加入一些 extra_vars``（如添加 ``"{ "hello": "world" }"）。

重新启动 j1 导致创建 j2，但是由于没有继承逻辑，而且 j1 没有 extra_vars，j2 将没有任何 extra_vars。

继续前面的示例，如果您启动了包含您在创建 j1 之后添加的 extra_vars 的作业模板，创建的重新启动作业 (j3) 将包括 extra_vars。重新启动 j3 会导致创建 j4，其中也包括 extra_vars。

Copyright © Red Hat, Inc.

Red Hat Ansible Automation Platform docs are generated using Sphinx using a theme provided by Read the Docs.