16. 任务模板¶

16.1. 创建任务模板¶

要创建新的任务模板

1. 单击 按钮，然后从菜单列表中选择 **任务模板**。

2. 将适当的详细信息输入以下字段

• **名称**：为作业输入名称。

• **描述**：根据需要输入任意描述（可选）。

• **作业类型**：选择作业类型

• **运行**：在启动时执行剧本，在选定的主机上运行 Ansible 任务。

• **检查**：执行剧本的“试运行”，并报告将要进行的更改，而不会实际进行更改。不支持检查模式的任务将被跳过，不会报告潜在的更改。

• **启动时提示**：如果选中，即使提供默认值，您也会在启动时被提示选择运行或检查作业类型。

注意

有关 *检查* 作业类型的更多信息，请参阅 Ansible 用户指南中的 使用检查模式。

• **清单**：从当前登录的 Tower 用户可用的清单中选择要与该任务模板一起使用的清单。

• **启动时提示**：如果选中，即使提供默认值，您也会在启动时被提示选择要针对该任务模板运行的清单。

• **项目**：从当前登录的 Tower 用户可用的项目中选择要与该任务模板一起使用的项目。

• **SCM 分支**：此字段仅在您选择允许分支覆盖的项目时才会出现。指定要在作业运行中使用的覆盖分支。如果留空，将使用项目中指定的 SCM 分支（或提交哈希或标签）。有关更多详细信息，请参阅 作业分支覆盖。

  • **启动时提示**：如果选中，即使提供默认值，您也会在启动时被提示选择 SCM 分支。

• **剧本**：从可用剧本中选择要与该任务模板一起启动的剧本。此字段将自动填充在为选定项目找到的项目基本路径中的剧本名称。或者，如果您想使用它来运行该剧本，您可以输入剧本的名称，例如文件的名称（如 foo.yml）。如果您输入的不是有效文件名，模板将显示错误，或导致作业失败。

• 凭据: 点击 按钮打开一个单独的窗口。从可用选项中选择要与该作业模板一起使用的凭据。如果列表很长，请使用下拉菜单列表按凭据类型进行筛选。

注意

某些凭据类型未列出，因为它们不适用于某些作业模板。

• 启动时的提示: 如果选中，在启动具有默认机器凭据的作业模板时，您将无法在“提示”对话框中删除默认机器凭据，除非在启动之前将其替换为其他机器凭据。或者，您可以根据需要添加更多凭据。以下是此类消息的示例

  

• 分叉: 执行剧本时要使用的并行或同时进程数。值为零使用 Ansible 默认设置，即 5 个并行进程，除非在 /etc/ansible/ansible.cfg 中被覆盖。

• 限制: 用于进一步限制由剧本管理或影响的宿主列表的宿主模式。多个模式可以用冒号 (":") 分隔。与核心 Ansible 一样，"a:b" 表示“在组 a 或 b 中”，"a:b:&c" 表示“在 a 或 b 中，但必须在 c 中”，"a:!b" 表示“在 a 中，并且肯定不在 b 中”。

• 启动时的提示: 如果选中，即使提供了默认值，您也会在启动时被提示选择限制。

  注意

  有关更多信息和示例，请参阅 Ansible 文档中的 模式。

• 详细程度: 控制 Ansible 在剧本执行时产生的输出级别。从普通到各种详细或调试设置中选择详细程度。这仅在“详细信息”报表视图中显示。详细日志记录包括所有命令的输出。调试日志记录非常详细，包括有关 SSH 操作的信息，这些信息在某些支持实例中可能很有用。大多数用户不需要查看调试模式输出。

  警告

  详细程度 5 会导致 Tower 在作业运行时严重阻塞，这可能会延迟报告作业已完成（即使它已完成），并可能导致浏览器选项卡锁定。

• 启动时的提示: 如果选中，即使提供了默认值，您也会在启动时被提示选择详细程度。

• 作业标签: 提供一个用逗号分隔的剧本标签列表，以指定应执行剧本的哪些部分。

• 启动时的提示: 如果选中，即使提供了默认值，您也会在启动时被提示选择作业标签。

• 跳过标签: 提供一个用逗号分隔的剧本标签列表，以跳过要执行的剧本的某些任务或部分。

• 启动时的提示: 如果选中，即使提供了默认值，您也会在启动时被提示选择要跳过的标签。

注意

有关标签和示例的更多信息，请参阅 Ansible 文档中的 标签。

• 标签: 提供可选标签来描述此作业模板，例如“dev”或“test”。标签可用于在 Tower 显示中对作业模板和已完成作业进行分组和筛选。

• 标签是在添加到作业模板时创建的。标签使用作业模板中提供的项目与单个组织相关联。如果组织成员具有编辑权限（例如管理员角色），他们可以在作业模板上创建标签。

• 保存作业模板后，标签将显示在作业模板概述的“扩展”视图中。

• 点击标签旁边的“x”将其删除。当删除标签，并且不再与作业或作业模板相关联时，该标签将从组织标签列表中永久删除。

• 作业在启动时从作业模板继承标签。如果从作业模板中删除标签，它也会从作业中删除。

  

• 实例组: 点击 按钮打开一个单独的窗口。选择要在此作业模板上运行的实例组。如果列表很长，请使用搜索来缩小选项范围。

• 作业切片: 指定要运行此作业模板的切片数。每个切片将对清单的一部分运行相同的任务。有关作业切片的更多信息，请参阅 作业切片。

• 超时: 允许您指定 Tower 在取消任务之前可以运行任务的时间长度（以秒为单位）。默认为 0，表示没有作业超时。

• 显示更改: 允许您查看 Ansible 任务所做的更改。

• 启动时的提示: 如果选中，即使提供了默认值，您也会在启动时被提示选择是否显示更改。

• 选项: 根据需要指定启动此模板的选项。

• 启用特权提升: 如果启用，则以管理员身份运行此剧本。这相当于将 --become 选项传递给 ansible-playbook 命令。

• 启用配置回调: 使宿主能够通过 Tower API 回调到 Tower，并调用从此作业模板启动作业。有关更多信息，请参阅 配置回调。

• 启用 Webhook: 打开与预定义 SCM 系统 Web 服务交互的能力，该服务用于启动作业模板。当前支持的 SCM 系统是 GitHub 和 GitLab。

如果启用 Webhook，其他字段将显示，提示您提供更多信息

• Webhook 服务: 选择要监听来自其 Webhook 的服务

• Webhook 凭据: 可选地，提供 GitHub 或 GitLab 个人访问令牌 (PAT) 作为凭据，用于向 Webhook 服务发送状态更新。在选择它之前，必须存在凭据。请参阅 凭据类型 以创建一个凭据。

在保存后，其他字段将显示，并在查看或编辑时保留。

• Webhook URL: 使用将 POST 请求发送到的 Webhook 服务的 URL 自动填充。

• Webhook 密钥: 生成的共享密钥，供 Webhook 服务用于对发送到 Tower 的有效负载进行签名。必须在 Webhook 服务的设置中配置此密钥，以便 Tower 接受来自此服务的 Webhook。

有关设置 Webhook 的更多信息，请参阅 使用 Webhook。

• 启用并发作业: 如果作业彼此之间没有依赖关系，则允许队列中的作业同时运行。如果您想同时运行作业切片，请选中此框。有关更多信息，请参阅 Ansible Tower 容量确定和作业影响。

• 启用事实缓存: 启用后，Tower 将为与运行的作业相关的清单中的所有宿主激活 Ansible 事实缓存插件。

• 额外变量:

• 将额外的命令行变量传递给剧本。这是 Ansible 文档中记录的 ansible-playbook 的“ -e”或“ –extra-vars”命令行参数，在运行时定义变量。

• 使用 YAML 或 JSON 提供键值对。这些变量具有最高的优先级，并覆盖在其他地方指定的其他变量。示例值可能是

  git_branch: production
  release_version: 1.5
  

有关额外变量的更多信息，请参阅 额外变量。

• 启动时的提示: 如果选中，即使提供了默认值，您也会在启动时被提示选择命令行变量。

注意

如果您希望能够在计划上指定 extra_vars，您必须为作业模板上的额外变量选择启动时的提示，或在作业模板上启用调查，然后这些已回答的调查问题将成为 extra_vars。

3. 完成作业模板详细信息的配置后，点击保存。

保存模板不会退出作业模板页面，而是停留在作业模板详细信息视图中，以供进一步编辑（如果需要）。保存模板后，您可以点击启动来启动作业，或者继续添加有关模板的更多属性，例如权限、通知、查看已完成作业，以及添加调查（如果作业类型不是扫描）。在启动之前，您必须先保存模板，否则启动按钮将保持灰色不可用。

当新创建的模板出现在屏幕底部的模板列表中时，您可以验证模板是否已保存。

16.2. 添加权限¶

权限选项卡允许您查看、授予、编辑和删除与用户和团队成员相关的关联权限。要将权限分配给特定用户的资源

1. 点击权限选项卡。

2. 点击 按钮打开添加用户/团队窗口。

3. 指定将拥有访问权限的用户或团队，然后为他们分配特定角色

1. 点击选择用户或团队姓名旁边的复选框（一个或多个）以选择它们。

注意

您可以通过在不保存的情况下在用户和团队选项卡之间导航来同时选择多个用户和团队。

完成选择后，窗口将扩展，允许您从下拉菜单列表中为选择的每个用户或团队选择一个角色。

上面的示例显示了与清单相关的选项。不同的资源具有不同的可用选项

• 管理员允许读取、运行和编辑权限（适用于所有资源）

• 使用允许在作业模板中使用资源（适用于除作业模板之外的所有资源）

• 更新允许通过 SCM 更新更新项目（适用于项目和清单）

• 临时允许使用临时命令（适用于清单）

• 执行允许启动作业模板（适用于作业模板）

• 读取允许仅查看访问（适用于所有资源）

提示

使用角色选择窗格中的密钥按钮来显示每个角色的描述。有关更多信息，请参阅本指南的 角色 部分。

2. 选择要应用于所选用户或团队的角色。

注意

您可以通过在不保存的情况下在用户和团队选项卡之间导航来将角色分配给多个用户和团队。

4. 查看您为每个用户和团队分配的角色。

5. 完成后点击保存，添加用户/团队窗口将关闭，以显示为每个用户和团队分配的更新角色。

   

要删除特定用户的权限，请点击其资源旁边的取消关联 (x) 按钮。

这将启动一个确认对话框，要求您确认取消关联。

16.3. 使用通知¶

点击通知选项卡，您可以查看您设置的任何通知集成。

使用切换开关启用或禁用要与您的特定模板一起使用的通知。有关更多详细信息，请参阅 启用和禁用通知。

如果尚未设置任何通知，请点击灰色框内的通知链接以创建新的通知。

有关配置各种通知类型的更多详细信息，请参阅 通知类型。

16.4. 查看已完成作业¶

已完成作业选项卡提供了已运行作业模板的列表。单击展开以查看每个作业的详细信息，包括其状态、ID 和名称；作业类型、开始和完成时间、谁启动了作业；以及使用了哪些模板、清单、项目和凭据。您可以使用任何这些条件过滤已完成作业的列表。

此列表中显示的切片作业将相应标记，并显示已运行的切片作业数量。

16.5. 调度¶

从调度选项卡访问特定作业模板的调度。

16.5.1. 调度作业模板¶

要调度作业模板运行，请单击调度选项卡。

• 如果调度已设置；查看、编辑或启用/禁用您的调度首选项。

• 如果尚未设置调度，请参阅调度以获取更多信息。

如果为凭据字段选择了启动时提示，并且您创建或编辑作业模板的调度信息，则提示按钮将显示在调度表单的底部。您将无法在提示对话框中删除默认机器凭据，除非用另一个机器凭据替换它，然后才能保存它。以下是此类消息的示例

注意

要能够在调度上设置 extra_vars，您必须在作业模板上为额外变量选择启动时提示，或在作业模板上启用调查，然后这些已回答的调查问题将变为 extra_vars。

16.6. 调查¶

在作业模板创建或编辑屏幕中，运行或检查类型的作业将提供设置调查的方法。调查为剧本设置了额外的变量，类似于“提示输入额外变量”的方式，但以用户友好的问答方式。调查还允许验证用户输入。单击 按钮以创建调查。

调查的用例很多。例如，如果运营团队希望为开发人员提供一个“推送到暂存环境”按钮，他们可以在没有高级 Ansible 知识的情况下运行它。启动时，此任务可能会提示用户回答以下问题：“我们应该发布哪个标签？”

可以提出多种类型的问题，包括多项选择题。

16.6.1. 创建调查¶

要创建调查

1. 单击 按钮以调出添加调查窗口。

使用屏幕顶部的开/关切换按钮可以快速激活或停用此调查提示。

2. 调查可以包含任意数量的问题。对于每个问题，请输入以下信息

• 名称：要问用户的的问题

• 描述：（可选）对向用户提出要求的描述。

• 答案变量名称：用于存储用户响应的 Ansible 变量名称。这是剧本要使用的变量。变量名不能包含空格。

• 答案类型：从以下问题类型中选择。

  • 文本：一行文本。您可以为此答案设置最小和最大长度（以字符为单位）。

  • 文本区域：一个多行文本字段。您可以为此答案设置最小和最大长度（以字符为单位）。

  • 密码：响应将被视为敏感信息，就像实际密码一样。您可以为此答案设置最小和最大长度（以字符为单位）。

  • 多项选择（单选）：选项列表，一次只能选择一个。在多项选择选项框中输入选项，每行一个。

  • 多项选择（多选）：选项列表，可以同时选择任意数量的选项。在多项选择选项框中输入选项，每行一个。

  • 整数：一个整数。您可以为此答案设置最小和最大长度（以字符为单位）。

  • 浮点数：一个十进制数。您可以为此答案设置最小和最大长度（以字符为单位）。

• 默认答案：问题的默认答案。此值在界面中预先填充，如果用户没有提供答案，则使用此值。

• 必填：用户是否需要回答此问题。

3. 输入问题信息后，单击 按钮以添加问题。

调查的风格化版本将显示在预览窗格中。对于任何问题，您可以单击编辑按钮以编辑问题，单击删除按钮以删除问题，并单击并拖动网格图标以重新排列问题的顺序。

4. 返回左侧窗格以添加更多问题。

5. 完成后，单击保存以保存调查。

16.7. 启动作业模板¶

Ansible Tower 的一个主要优势是 Ansible 剧本的按钮式部署。您可以在 Tower 中轻松配置一个模板，以存储您通常在命令行上传递给 ansible-playbook 的所有参数，不仅包括剧本，还包括清单、凭据、额外变量以及您可以在命令行上指定的选项和设置。

更轻松的部署促进了一致性，通过每次以相同的方式运行您的剧本，并允许您委托职责，即使是不熟悉 Ansible 的用户也可以运行其他人编写的 Tower 剧本。

通过以下任何方式启动作业模板

• 从 导航链接访问作业模板列表，或在作业模板详细信息视图中，滚动到底部以从模板列表中访问 按钮。

• 在要启动的作业模板的作业模板详细信息视图中，单击启动。

作业可能需要其他信息才能运行。启动时可能会请求以下数据

• 已设置的凭据

• 如果为任何参数选择了选项 Prompt on Launch

• 已设置为询问的密码或密码短语

• 调查，如果已为作业模板配置调查

• 额外变量，如果作业模板请求

注意

如果作业具有用户提供的价值，则在重新启动时将尊重这些价值。如果用户没有指定值，则作业使用作业模板中的默认值。作业不会按原样重新启动。它们将使用重新应用于作业模板的用户提示重新启动。

以下是启动作业的示例，该作业提示输入作业标签，并运行在 调查 中创建的示例调查。

注意

在一个选项卡上提供值，然后返回到上一个选项卡，然后继续到下一个选项卡将导致必须在其余选项卡上重新提供值。确保按照提示出现的顺序填写选项卡以避免这种情况。

除了在作业模板和调查中设置的任何额外变量之外，Tower还会自动将以下变量添加到作业环境中

• tower_job_id：此作业运行的作业 ID

• tower_job_launch_type：描述以指示作业的启动方式

  • 手动：作业是由用户手动启动的。

  • 重新启动：作业是通过重新启动启动的。

  • 回调：作业是通过主机回调启动的。

  • 调度：作业是从调度启动的。

  • 依赖项：作业是作为另一个作业的依赖项启动的。

  • 工作流：作业是从工作流作业启动的。

  • 同步：作业是从项目同步启动的。

  • scm：作业是作为清单 SCM 同步创建的。

• tower_job_template_id：此作业运行使用的作业模板 ID

• tower_job_template_name：此作业使用的作业模板名称

• tower_project_revision：此特定作业使用的源树的修订标识符（它与作业的字段 scm_revision 相同）

• tower_user_email：启动此作业的 Tower 用户的电子邮件。回调或调度作业不可用。

• tower_user_first_name：启动此作业的 Tower 用户的姓氏。回调或调度作业不可用。

• tower_user_id：启动此作业的 Tower 用户的 ID。回调或调度作业不可用。

• tower_user_last_name：启动此作业的 Tower 用户的姓氏。回调或调度作业不可用。

• tower_user_name：启动此作业的 Tower 用户的用户名。回调或调度作业不可用。

• tower_schedule_id：如果适用，启动此作业的调度的 ID

• tower_schedule_name：如果适用，启动此作业的调度的名称

• tower_workflow_job_id: 如果适用，启动此作业的工作流作业的 ID

• tower_workflow_job_name: 如果适用，启动此作业的工作流作业的名称。请注意，这也与工作流作业模板相同。

• tower_inventory_id: 如果适用，此作业使用的库存的 ID

• tower_inventory_name: 如果适用，此作业使用的库存的名称

所有变量也都有一个“awx”前缀，例如，awx_job_id。

启动后，Tower 会自动将 Web 浏览器重定向到此作业的作业状态页面，该页面位于 **作业** 选项卡下。

注意

您可以从列表视图中重新启动最近的作业，以便在指定库存中的所有主机或仅失败的主机上重新运行。有关更多详细信息，请参阅Ansible Tower 用户指南中的 作业。

当切片作业运行时，作业列表会显示工作流和作业切片，以及一个链接，可以单独查看它们的详细信息。

16.8. 复制作业模板¶

Ansible Tower 3.0 引入了复制作业模板的功能。如果您选择复制作业模板，则 **不会** 复制任何关联的计划、通知或权限。用户或管理员创建作业模板副本时，必须重新创建计划和通知。复制作业模板的用户将被授予管理员权限，但不会将任何权限分配（复制）到作业模板。

1. 从 导航链接访问作业模板列表，或在作业模板详细信息视图中，滚动到底部以从模板列表中访问它。

2. 单击 按钮。

将打开一个新的模板，其中包含复制的模板名称和时间戳。

3. 用新名称替换 **名称** 字段的内容，并提供或修改其他字段中的条目以完成此页面。

4. 完成后单击 **保存**。

16.9. 扫描作业模板¶

从 Ansible Tower 3.2 开始，不再支持扫描作业。此系统跟踪功能用作捕获和存储事实作为历史数据的一种方式。现在，事实通过事实缓存存储在 Tower 中。有关更多信息，请参见 事实缓存。

如果您在 Ansible Tower 3.2 之前在系统中拥有作业模板扫描作业，它们已转换为运行类型（就像普通作业模板一样）并保留了其关联资源（即库存、凭据）。没有相关项目的作业模板扫描作业默认分配一个特殊的剧本，或者您可以使用自己的扫描剧本指定一个项目。为每个指向 https://github.com/ansible/tower-fact-modules 的组织创建了一个项目，并将作业模板设置为剧本 https://github.com/ansible/tower-fact-modules/blob/master/scan_facts.yml。

16.9.1. 事实扫描剧本¶

扫描作业剧本 scan_facts.yml 包含三个 fact scan modules 的调用 - 包、服务和文件，以及 Ansible 的标准事实收集。scan_facts.yml 剧本文件如下所示

- 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 并使用 become 是可能的凭据。您可以通过从选项菜单中选中 **启用特权升级** 来启用 become

注意

如果您在 Ansible Tower 3.1.x 中维护了扫描作业模板，然后升级到 Ansible Tower 3.2，则会自动为您创建一个新的“Tower Fact Scan - Default”项目。此项目包含以前在早期版本的 Ansible Tower 中使用的旧扫描剧本。

---

- 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

---

- 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

- hosts: all
  gather_facts: false
  tasks:
    - scan_foo:

def main():
    module = AnsibleModule(
        argument_spec = dict())

    foo = [
      {
        "hello": "world"
      },
      {
        "foo": "bar"
      }
    ]
    results = dict(ansible_facts=dict(foo=foo))
    module.exit_json(**results)

main()

[
   {
     "hello": "world"
   },
   {
     "foo": "bar"
   }
 ]

16.10. 事实缓存¶

Tower 可以通过 Ansible Fact Cache 插件按主机存储和检索事实。此行为可以在每个作业模板的基础上进行配置。事实缓存默认情况下处于关闭状态，但可以启用它来为与正在运行的作业相关的库存中的所有主机提供事实请求。这使您能够使用带有 --limit 的作业模板，同时仍然可以访问整个库存主机事实。可以通过在作业选项卡下的配置 Tower 界面中指定一个全局超时设置（以秒为单位）来指定插件对每个主机强制执行的全局超时设置

启动使用事实缓存的作业 (use_fact_cache=True) 后，Tower 将存储与作业相关联的库存中每个主机关联的所有 ansible_facts。与 Ansible Tower 一起提供的 Ansible Fact Cache 插件仅在使用事实缓存 (use_fact_cache=True) 的作业上启用。

当启用事实缓存 (use_fact_cache=True) 的作业完成运行时，Tower 将恢复库存中所有主机的所有记录。任何更新时间比每个主机当前存储的事实更新的记录都将在数据库中更新。

新事实和已更改的事实将通过 Tower 的日志记录工具进行记录。具体而言，对于 system_tracking 命名空间或记录器。日志记录有效负载将包括以下字段

• host_name

• inventory_id

• ansible_facts

其中 ansible_facts 是 Tower 库存中 host_name 的所有 Ansible 事实的字典，inventory_id。

注意

如果主机名包含正斜杠 (/)，则事实缓存将无法为此主机使用。如果您有一个包含 100 个主机的库存，并且其中一个主机在名称中包含 /，则其中 99 个主机仍将收集事实。

16.10.1. 事实缓存的优势¶

事实缓存与运行事实收集相比节省了大量时间。如果您在针对一千个主机和 fork 运行的作业中有一个剧本，那么您可能会轻松地花费 10 分钟来收集所有这些主机的 facts。但是，如果您定期运行作业，则第一次运行将缓存这些 facts，下次运行将直接从数据库中提取它们。这将显著缩短针对大型库存（包括智能库存）运行的作业的运行时间。

注意

不要修改 ansible.cfg 文件以应用事实缓存。自定义事实缓存可能会与 Tower 的事实缓存功能冲突。建议使用随 Ansible Tower 提供的事实缓存模块。事实缓存不支持孤立节点。

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

要清除事实，您需要运行 Ansible clear_facts 元任务。以下是一个使用 Ansible clear_facts 元任务的剧本示例。

- hosts: all
  gather_facts: false
  tasks:
    - name: Clear gathered facts from all currently targeted hosts
      meta: clear_facts

事实缓存的 API 终结点位于：http://<Tower server name>/api/v2/hosts/x/ansible_facts。

16.11. 利用云凭据¶

同步相应的云库存时可以使用云凭据。云凭据也可以与作业模板关联，并包含在运行时环境中供剧本使用。当前支持的云凭据

clouds:
  devstack:
    auth:
      auth_url: http://devstack.yoursite.com:5000/v2.0/
      username: admin
      password: your_password_here
      project_name: demo

- hosts: all
  gather_facts: false
  vars:
    config_file: "{{ lookup('env', 'OS_CLIENT_CONFIG_FILE') }}"
    nova_tenant_name: demo
    nova_image_name: "cirros-0.3.2-x86_64-uec"
    nova_instance_name: autobot
    nova_instance_state: 'present'
    nova_flavor_name: m1.nano

    nova_group:
      group_name: antarctica
      instance_name: deceptacon
      instance_count: 3
  tasks:
    - debug: msg="{{ config_file }}"
    - stat: path="{{ config_file }}"
      register: st
    - include_vars: "{{ config_file }}"
      when: st.stat.exists and st.stat.isreg

    - name: "Print out clouds variable"
      debug: msg="{{ clouds|default('No clouds found') }}"

    - name: "Setting nova instance state to: {{ nova_instance_state }}"
      local_action:
        module: nova_compute
        login_username: "{{ clouds.devstack.auth.username }}"
        login_password: "{{ clouds.devstack.auth.password }}"

- vsphere_guest:
    vcenter_hostname: "{{ lookup('env', 'VMWARE_HOST') }}"
    username: "{{ lookup('env', 'VMWARE_USER') }}"
    password: "{{ lookup('env', 'VMWARE_PASSWORD') }}"
    guest: newvm001
    from_template: yes
    template_src: centosTemplate
    cluster: MainCluster
    resource_pool: "/Resources"
    vm_extra_config:
      folder: MyFolder

16.12. 配置回调¶

配置回调是 Tower 的一项功能，允许主机自行启动剧本运行，而不必等待用户从 Tower 控制台启动作业来管理主机。请注意，配置回调 *仅* 用于在调用主机上运行剧本。配置回调旨在用于云突发，即：需要客户端到服务器通信进行配置（如传输授权密钥）的新实例，而不是对另一台主机运行作业。这使得在系统由另一系统（如 AWS 自动缩放或 kickstart 或 preseed 等操作系统配置系统）配置后自动配置系统，或在不直接调用 Tower API 的情况下以编程方式启动作业成为可能。启动的作业模板只针对请求配置的主机运行。

通常情况下，这将通过 firstboot 类型的脚本或 cron 访问。

要启用回调，请在作业模板中选中 *允许配置回调* 复选框。这将显示此作业模板的 **配置回调 URL**。

注意

如果您打算在使用动态清单的情况下使用 Tower 的配置回调功能，则应为作业模板中使用的清单组设置启动时更新。

回调还需要主机配置密钥，以确保具有 URL 的外部主机无法请求配置。单击 按钮为此回调创建唯一的主机密钥，或输入您自己的密钥。主机密钥可以在多个主机之间重复使用，以对多个主机应用此作业模板。如果您希望控制哪些主机可以请求配置，可以随时更改密钥。

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

http://<TOWER_SERVER_NAME>/api/v2/job_templates/1/callback/

此示例 URL 中的“1”是 Tower 中的作业模板 ID。

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

curl -k -f -i -H 'Content-Type:application/json' -XPOST -d '{"host_config_key": "cfbaae23-81c0-47f8-9a40-44493b82f06a"}' \
                  https://<TOWER_SERVER_NAME>/api/v2/job_templates/1/callback/

请求主机必须在您的清单中定义，才能使回调成功。如果 Tower 无法在您定义的清单之一中通过名称或 IP 地址找到主机，则请求将被拒绝。以这种方式运行作业模板时，自行启动剧本运行的主机必须在清单中。如果主机不在清单中，作业模板将以“无主机匹配”类型的错误消息失败。

注意

如果您的主机不在清单中，并且为清单组设置了 Update on Launch，Tower 将尝试在运行回调之前更新基于云的清单源。

成功的请求将在作业选项卡中生成一个条目，您可以在其中查看结果和历史记录。

虽然回调可以通过 REST 访问，但建议使用回调的方法是使用 Tower 附带的示例脚本之一 - /usr/share/awx/request_tower_configuration.sh（Linux/UNIX）或 /usr/share/awx/request_tower_configuration.ps1（Windows）。使用方式在文件的源代码中通过传递 -h 标志描述，如下所示

./request_tower_configuration.sh -h
Usage: ./request_tower_configuration.sh <options>

Request server configuration from Ansible Tower.

OPTIONS:
   -h      Show this message
   -s      Tower server (e.g. https://tower.example.com) (required)
   -k      Allow insecure SSL connections and transfers
   -c      Host config key (required)
   -t      Job template ID (required)
   -e      Extra variables
   -s      Number of seconds between retries (default: 60)

此脚本很智能，因为它知道如何重试命令，因此比简单的 curl 请求更可靠地使用回调。按照编写方式，脚本每分钟重试一次，最多重试十次。

注意

请注意，这是一个示例脚本。如果您需要在检测失败场景时有更动态的行为，则应该编辑此脚本，因为任何非 200 错误代码可能不是需要重试的瞬态错误。

您很可能将回调与 Tower 中的动态清单一起使用，例如从支持的云提供商之一中提取云清单。在这些情况下，除了设置 *启动时更新* 之外，请务必为清单源配置清单缓存超时，以避免对云 API 端点的频繁调用。由于 request_tower_configuration.sh 脚本每分钟轮询一次，最多轮询十次，因此建议的清单失效时间（在清单源本身配置）将是一到两分钟。

虽然我们建议不要从 cron 作业运行 request_tower_configuration.sh 脚本，但建议的 cron 间隔可能是每 30 分钟。重复配置可以轻松地通过 Tower 中的调度来处理，因此大多数用户使用回调的主要目的是启用一个基础映像，该映像在上线后会自动引导到最新的配置。为此，在第一次启动时运行是一个更好的做法。第一次启动脚本只是一些简单的 init 脚本，这些脚本通常会自行删除，因此您需要设置一个 init 脚本，该脚本调用 request_tower_configuration.sh 脚本的副本，并将其转换为自动缩放映像。

16.12.1. 将额外变量传递给配置回调¶

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

'{"extra_vars": {"variable1":"value1","variable2":"value2",...}}'

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

root@localhost:~$ curl -f -H 'Content-Type: application/json' -XPOST \
                 -d '{"host_config_key": "5a8ec154832b780b9bdef1061764ae5a", "extra_vars": "{\"foo\": \"bar\"}"}' \
                 http://<TOWER_SERVER_NAME>/api/v2/job_templates/1/callback

有关更多信息，请参阅 使用 Curl 启动作业。

16.13. 额外变量¶

注意

传递给作业启动 API 的 extra_vars 只有在以下情况之一成立时才会被接受

• 它们对应于已启用调查中的变量

• ask_variables_on_launch 设置为 True

当您传递调查变量时，它们会作为额外变量 (extra_vars) 在 Tower 中传递。这可能很棘手，因为将额外变量传递给作业模板（就像您对调查所做的那样）可能会覆盖从清单和项目传递的其它变量。

默认情况下，extra_vars 被标记为 !unsafe，除非您在作业模板的额外变量部分指定它们。这些变量是可信的，因为只有具有足够权限添加或编辑作业模板的用户才能添加它们。例如，嵌套变量在作为提示输入时不会展开，因为 Jinja 方括号被视为字符串。有关不安全变量的更多信息，请参见 不安全或原始字符串。

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

为了确保您需要传递的变量不会被覆盖，请确保通过在调查中重新定义它们来包含它们。请记住，可以在清单、组和主机级别定义额外变量。

注意

作业模板额外变量字典将与调查变量合并。

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

YAML 格式的配置

launch_to_orbit: true
satellites:
  - sputnik
  - explorer
  - satcom

JSON 格式的配置

{
  "launch_to_orbit": true,
  "satellites": ["sputnik", "explorer", "satcom"]
}

下表说明了 Ansible Tower 中变量优先级与 Ansible 中变量优先级的行为（层次结构）。

Ansible Tower 变量优先级层次结构（最后列出者优先）

16.13.1. 重新启动作业模板¶

无需手动重新启动作业，只需将 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。