21. 作业¶
一个 作业 是 Tower 启动 Ansible 剧本针对主机清单的实例。
作业链接显示作业列表及其状态 - 显示为成功完成或失败，或作为活动（正在运行）作业。默认视图是折叠的（**紧凑**），包含作业 ID、作业名称和作业类型，但您可以展开以查看更多信息。您可以根据各种标准对该列表进行排序，并执行搜索以过滤您感兴趣的作业。
您可以从此屏幕执行的操作包括查看特定作业的详细信息和标准输出、重新启动 (
) 作业或删除 (
) 作业。
从列表视图中，您可以重新启动最新的作业。您可以对指定清单中的所有主机重新运行，即使其中一些已经成功运行。这允许您重新运行作业，而无需再次对它们运行剧本。您还可以对所有失败的主机重新运行作业。这将有助于降低 Ansible Tower 节点的负载，因为它不需要再次处理成功的主机。
重新启动操作仅适用于重新启动剧本运行，不适用于项目/清单更新、系统作业、工作流作业等。
选择 **全部** 将重新启动所有主机。
选择 **失败** 将重新启动所有失败和无法访问的主机。
重新启动时，您将保留在同一页面。
使用 Tower 搜索功能根据各种标准查找作业。有关使用 Tower 搜索的详细信息，请参阅 搜索 章节。
单击任何类型的作业将带您到该作业的作业详细信息视图，该视图包含两个部分
**详细信息** 窗格提供有关作业的信息和状态
**标准输出** 窗格显示作业流程和输出
21.1. 作业详细信息 - 清单同步¶
注意
从 Ansible Tower 3.7 开始，可以在相关作业运行时执行清单更新。如果您有一个大型项目（约 10 GB），/tmp 上的磁盘空间可能是一个问题。
21.1.1. 详细信息¶
**详细信息** 窗格显示作业的基本状态及其开始时间。**详细信息** 窗格右上角的图标允许您重新启动 () 或删除 () 作业。
**详细信息** 窗格还提供有关作业执行的详细信息
**状态**：可以是以下任何一种
**待处理** - 清单同步已创建，但尚未排队或启动。任何作业，不仅仅是清单源同步，都将保持待处理状态，直到它实际上准备好在系统中运行。清单源同步未准备好的原因包括：当前正在运行的依赖项（所有依赖项必须完成才能执行下一步），或者它在配置的运行位置没有足够的容量。
**等待** - 清单同步正在队列中等待执行。
**运行** - 清单同步当前正在进行中。
**成功** - 清单同步作业成功。
**失败** - 清单同步作业失败。
**许可证错误**：仅对 **清单同步** 作业显示。如果为 True，则清单同步添加的主机导致 Tower 超过许可的管理主机数量。
**主机限制错误**：表示作业的清单属于已超出系统管理员定义的主机限制的组织。
**开始**：Tower 启动作业的时间戳。
**完成**：作业完成的时间戳。
**由...启动**：启动作业的用户的姓名。
**清单**：关联的清单组的名称。
**来源**：云清单的类型。
覆盖：如果为True，则从 Tower 库存中删除之前存在于外部源但现在已删除的任何主机和组。未由库存源管理的主机和组将被提升到下一个手动创建的组，如果没有手动创建的组可将其提升，则将其保留在库存的“全部”默认组中。如果为False，则库存更新过程不会触及外部源上未找到的本地子主机和组。
覆盖变量：如果为True，则将删除子组和主机的所有变量，并将其替换为外部源上找到的变量。如果为False，则执行了合并操作，将本地变量与外部源上找到的变量合并。
详细程度：Ansible 为库存源更新作业生成的输出级别。
环境：使用的虚拟环境。
执行节点：用于执行作业的节点。
实例组：与该作业一起使用的实例组的名称（tower 是默认实例组）。
在适当的情况下，单击这些项目可以查看相应的作业模板、项目和其他 Tower 对象。
21.1.2. 标准输出¶
标准输出窗格显示运行库存同步剧本的完整结果。这将显示与您通过 Ansible 命令行运行时看到的相同信息，可以用于调试。标准输出窗格右上角的图标允许您将输出切换为主要视图 (
) 或下载输出 (
)。
默认情况下，所有剧本运行的ANSIBLE_DISPLAY_ARGS_TO_STDOUT 设置为 False。这与 Ansible 的默认行为一致。这会导致 Tower 停止在作业详细信息界面中显示任务标头中的任务参数，以避免将某些敏感模块参数泄露到标准输出。如果您希望恢复先前的行为（尽管存在安全隐患），您可以通过 AWX_TASK_ENV 配置设置将 ANSIBLE_DISPLAY_ARGS_TO_STDOUT 设置为 True。有关更多详细信息，请参阅 ANSIBLE_DISPLAY_ARGS_TO_STDOUT。
21.2. 作业详细信息 - SCM¶
21.2.1. 详细信息¶
**详细信息** 窗格显示作业的基本状态及其开始时间。**详细信息** 窗格右上角的图标允许您重新启动 () 或删除 () 作业。
详细信息窗格提供有关作业执行的详细信息。
名称：关联的库存组的名称。
**状态**：可以是以下任何一种
待处理 - SCM 作业已创建，但尚未排队或启动。任何作业，不仅是 SCM 作业，都会一直处于待处理状态，直到系统实际准备好运行它为止。SCM 作业未准备好的原因包括当前正在运行的依赖项（所有依赖项都必须完成才能执行下一步），或者在它配置运行的位置没有足够的容量。
等待 - SCM 作业正在队列中等待执行。
正在运行 - SCM 作业当前正在进行中。
成功 - 上一个 SCM 作业成功。
失败 - 上一个 SCM 作业失败。
**开始**：Tower 启动作业的时间戳。
**完成**：作业完成的时间戳。
已用时间：作业花费的总时间。
启动类型：手动 或 计划。
项目：项目的名称。
在适当的情况下，单击这些项目可以查看相应的作业模板、项目和其他 Tower 对象。
21.2.2. 标准输出¶
标准输出窗格显示运行 SCM 更新的完整结果。这将显示与您通过 Ansible 命令行运行时看到的相同信息，可以用于调试。标准输出窗格右上角的图标允许您将输出切换为主要视图 () 或下载输出 ()。
21.3. 作业详细信息 - 剧本运行¶
从作业模板页面启动作业后，也可以访问剧本运行作业的作业详细信息视图。
21.3.1. 详细信息¶
**详细信息** 窗格显示作业的基本状态及其开始时间。**详细信息** 窗格右上角的图标允许您重新启动 () 或删除 () 作业。
详细信息窗格提供有关作业执行的详细信息。
**状态**：可以是以下任何一种
待处理 - 剧本运行已创建，但尚未排队或启动。任何作业，不仅是剧本运行，都会一直处于待处理状态，直到系统实际准备好运行它为止。剧本运行未准备好的原因包括当前正在运行的依赖项（所有依赖项都必须完成才能执行下一步），或者在它配置运行的位置没有足够的容量。
等待 - 剧本运行正在队列中等待执行。
正在运行 - 剧本运行当前正在进行中。
成功 - 上一个剧本运行成功。
失败 - 上一个剧本运行失败。
模板：启动该作业的作业模板的名称。
**开始**：Tower 启动作业的时间戳。
**完成**：作业完成的时间戳。
已用时间：作业花费的总时间。
启动者：启动该作业的用户、作业或计划的扫描作业的名称。
库存：选择用于针对其运行该作业的库存。
机器凭据：该作业中使用的凭据的名称。
详细程度：创建作业模板时设置的详细程度级别。
额外变量：创建作业模板时传递的任何额外变量都会在此处显示。
在适当的情况下，单击这些项目可以查看相应的作业模板、项目和其他 Tower 对象。
21.3.2. 标准输出窗格¶
标准输出窗格显示运行 Ansible 剧本的完整结果。这将显示与您通过 Ansible 命令行运行时看到的相同信息，可以用于调试。您可以查看事件摘要、主机状态和主机事件。标准输出窗格右上角的图标允许您将输出切换为主要视图 () 或下载输出 ()。
21.3.2.1. 事件摘要¶
事件摘要捕获作为该剧本的一部分运行的事件的统计数据。
剧本的数量
任务的数量
主机的数量
运行作业模板的已用时间
21.3.2.2. 主机状态栏¶
主机状态栏贯穿标准输出窗格的顶部。将鼠标悬停在主机状态栏的某一部分上，与该特定状态关联的主机数量将显示出来。
21.3.2.3. 搜索¶
使用 Tower 搜索查找特定事件、主机名及其状态。要仅筛选具有特定状态的某些主机，请指定以下有效状态之一。
已更改：剧本任务已实际执行。由于 Ansible 任务应编写为幂等的，因此任务可能会在主机上不执行任何操作的情况下成功退出。在这些情况下，任务将返回 Ok，但不会更改。
失败：任务失败。对该主机的进一步剧本执行已停止。
确定：剧本任务返回“Ok”。
无法访问：主机无法从网络访问，或者与其关联着其他致命错误。
已跳过：剧本任务已跳过，因为主机无需进行任何更改即可达到目标状态。
已恢复：在 Ansible 2.8 中引入，这显示了失败的任务，然后执行恢复部分。
已忽略：在 Ansible 2.8 中引入，这显示了失败的任务，并且配置了
ignore_errors: yes。
这些状态还显示在每个标准输出窗格的底部，在一个名为主机摘要字段的“统计信息”组中。
以下示例显示了仅包含失败主机的搜索。
有关使用 Tower 搜索的更多详细信息，请参阅 搜索 章节。
21.3.2.4. 标准输出视图¶
标准输出视图显示特定作业上发生的事件。默认情况下，所有行都处于展开状态，以便显示所有详细信息。使用全部折叠按钮 (
) 切换到仅包含剧本和任务标题的视图。单击 (
) 按钮以查看标准输出的所有行。
或者，您可以通过单击其旁边的箭头图标来显示特定剧本或任务的所有详细信息。单击从侧面到向下的箭头以展开与该剧本或任务关联的行。单击箭头返回侧面位置以折叠并隐藏这些行。
在展开/折叠模式下查看详细信息时需要注意的事项。
每个未折叠的显示行都具有相应的行号和开始时间。
在剧本或任务完成后，剧本或任务的开头将有一个展开/折叠图标。
如果查询特定剧本或任务，它将在其完成进程的末尾显示为折叠状态。
在某些情况下，将出现错误消息，指出输出可能太大而无法显示。当事件超过 4000 个时，就会发生这种情况。使用搜索和筛选特定事件来绕过错误。
将鼠标悬停在标准输出视图中的事件行上，该行上方将显示一个工具提示，其中显示了受此任务影响的总主机数量以及查看其状态细分的选项。
从标准输出窗格中单击事件行，将在单独的窗口中显示主机事件对话框。该窗口显示受该特定事件影响的主机。
注意
升级到 Tower 的最新版本涉及逐步迁移所有历史剧本输出和事件。此迁移过程是渐进的，并在安装完成后自动在后台进行。具有大量历史作业输出（数十 GB 或数百 GB 输出）的安装可能会注意到在迁移完成之前缺少作业输出。最新的数据将显示在输出的顶部，其次是较旧的事件。迁移具有大量事件的作业可能比迁移具有少量事件的作业需要更长时间。
21.3.2.5. 主机事件¶
主机事件对话框显示有关受选定事件及其关联的剧本和任务影响的主机的信息。
主机
状态
唯一的ID
创建时间戳
剧本的名称
任务的名称
如果适用，任务的 Ansible 模块以及该模块的任何参数
任务的标准输出
要以 JSON 格式查看结果，请单击JSON 选项卡。
21.4. Ansible Tower 容量确定和作业影响¶
本节介绍如何确定实例组的容量及其对作业的影响。对于容器组，请参阅Ansible Tower 管理指南中的容器容量限制。
Ansible Tower 的容量系统根据实例可用的资源量和正在运行的作业的大小（称为*影响*）来确定实例上可以运行多少个作业。 用于确定此值的算法完全基于两件事
系统可用的内存量（
mem_capacity）系统可用的 CPU 量（
cpu_capacity）
容量也会影响实例组。 由于组是由实例组成的，因此实例可以分配给多个组。 这意味着对一个实例的影响可能会影响其他组的总体容量。
实例组（而不是实例本身）可以分配给作业在不同级别使用（参见Clustering）。 当任务管理器准备其图以确定作业将在哪个组上运行时，它将把实例组的容量提交给尚未或未准备好开始运行的作业。
最后，在较小的配置中，如果只有一个实例可用于运行作业，则任务管理器将允许该作业在实例上运行，即使这会导致实例超过容量。 这保证了作业本身不会因为系统配置不足而卡住。
因此，容量和影响不是相对于作业和实例/实例组的零和系统。
有关切片作业及其对容量的影响的信息，请参见Job slice execution behavior。
21.4.1. 容量算法的资源确定¶
容量算法的定义是为了确定系统能够同时运行多少个 fork。 这控制着 Ansible 本身将同时与多少个系统通信。 通常情况下，增加 Tower 系统正在运行的 fork 数量将通过并行执行更多工作来加快作业运行速度。 权衡是这将增加系统负载，这可能会导致整体工作速度变慢。
Tower 在确定容量时可以运行两种模式。 mem_capacity（默认值）将允许您过度分配 CPU 资源，同时保护系统免受内存不足的影响。 如果您的大部分工作不是 CPU 密集型，那么选择此模式将最大化 fork 数量。
21.4.1.1. 内存相关的容量¶
mem_capacity 是相对于每个 fork 所需的内存量计算的。 考虑到 Tower 内部组件的开销，这大约是每个 fork 100MB。 在考虑可用于 Ansible 作业的内存量时，容量算法将保留 2GB 的内存来考虑其他 Tower 服务的存在。 该算法的公式如下
(mem - 2048) / mem_per_fork
例如
(4096 - 2048) / 100 == ~20
因此，具有 4GB 内存的系统能够运行 20 个 fork。 值 mem_per_fork 可以通过设置 Tower 设置值（或环境变量）SYSTEM_TASK_FORKS_MEM 来控制，该值默认为 100。
21.4.1.2. CPU 相关的容量¶
通常情况下，Ansible 工作负载可能是相当 CPU 密集型的。 在这些情况下，有时减少同时工作负载可以使更多任务更快地运行，并减少这些作业的平均完成时间。
正如 Tower mem_capacity 算法使用每个 fork 所需的内存量一样，cpu_capacity 算法会查看每个 fork 所需的 CPU 资源量。 此值的基线值为每个核心 4 个 fork。 该算法的公式如下
cpus * fork_per_cpu
例如，一个 4 核系统
4 * 4 == 16
值 fork_per_cpu 可以通过设置 Tower 设置值（或环境变量）SYSTEM_TASK_FORKS_CPU 来控制，该值默认为 4。
21.4.2. 容量作业影响¶
在选择容量时，了解每种作业类型如何影响容量非常重要。
了解 fork 对 Ansible 的意义很有帮助：https://www.ansible.org.cn/blog/ansible-performance-tuning（参见“了解您的 fork”部分）。
Ansible 的默认 fork 值为 5。 但是，如果 Tower 知道您运行的系统少于该值，那么实际的并发值将更低。
当运行作业时，Tower 将在所选的 fork 数量中添加 1，以补偿 Ansible 父进程。 因此，如果您对 5 个系统运行一个剧本，fork 值为 5，那么从作业影响的角度来看，实际的 fork 值将为 6。
21.4.2.1. Tower 中作业类型的影响¶
作业和临时作业遵循上述模型，fork + 1。 如果您在作业模板上设置了 fork 值，您的作业容量值将是提供的 fork 值和您拥有的主机数量的最小值加 1。 加 1 是为了考虑 Ansible 父进程。
实例容量决定哪些作业被分配给任何特定实例。 如果作业和临时命令具有更高的 fork 值，则它们将使用更多容量。
其他作业类型具有固定影响
清单更新：1
项目更新：1
系统作业：5
如果您没有在作业模板上设置 fork 值，您的作业将使用 Ansible 的默认 fork 值 5。 即使 Ansible 默认为 5 个 fork，如果您的作业少于 5 个主机，它将使用更少的 fork。 通常，设置高于系统所能承受的 fork 值会导致内存不足或过度分配 CPU 问题。 因此，您使用的作业模板 fork 值应该适合系统。 如果您有使用 1000 个 fork 的剧本，但没有一个系统单独具有那么大的容量，那么您的系统规模过小，并且有发生性能或资源问题的风险。
21.4.2.2. 选择正确的容量¶
从 CPU 密集型或内存密集型容量限制中选择容量本质上是在最小 fork 数量或最大 fork 数量之间进行选择。 在上面的例子中，CPU 容量允许最大 16 个 fork，而内存容量允许 20 个 fork。 对于某些系统，两者之间的差异可能很大，而且您可能希望在这两者之间取得平衡。
实例字段 capacity_adjustment 允许您选择要考虑多少个算法。 它表示为介于 0.0 和 1.0 之间的值。 如果设置为 1.0，则将使用最大值。 上面的例子涉及内存容量，因此将选择 20 个 fork。 如果设置为 0.0，则将使用最小值。 值 0.5 将是两种算法之间的 50/50 平衡，这将是 18
16 + (20 - 16) * 0.5 == 18
要在 Tower 用户界面中查看或编辑容量，请选择实例组的**实例**选项卡。
21.5. 作业分支覆盖¶
项目在 scm_branch 字段中指定要从源代码控制中使用的分支、标签或引用。 这些由项目详细信息字段中指定的值表示，如所示。
项目可以选择“允许分支覆盖”。 选中后，项目管理员可以将分支选择权委派给使用该项目的作业模板（仅要求项目 use_role）。
作业模板的管理员可以通过选中作业模板的 SCM 分支字段旁边的**启动时提示**框，进一步将该权限委派给执行作业模板的用户（仅要求作业模板 execute_role）。
21.5.1. 源代码树复制行为¶
每个作业运行都有自己的私有数据目录。 该目录包含给定 scm_branch 的项目源代码树的副本，作业正在运行。 作业可以自由地在项目文件夹中进行更改，并在运行时使用这些更改。 此文件夹是临时的，并在作业运行结束时清理。
如果选中**清除**，Tower 会通过在与git、Subversion 和Mercurial相关的 Ansible 模块中使用 force 参数来丢弃其本地存储库副本中的修改后的文件。
21.5.2. 项目修订行为¶
通常，在项目更新期间，默认分支的修订（在项目的**SCM 分支**字段中指定）在更新时存储，使用该项目的作业将使用此修订。 在作业中提供非默认的**SCM 分支**（不是提交哈希或标签），作业开始之前会立即从源代码控制远程拉取最新修订。 此修订在作业的**修订**字段及其相应的项目更新中显示。
因此，非默认分支的离线作业运行是不可能的。 为了确保作业运行源代码控制中的静态版本，请使用标签或提交哈希。 项目更新不会保存所有分支的修订，只保存项目默认分支的修订。
**SCM 分支**字段不会进行验证，因此项目必须更新以确保其有效。 如果提供或提示此字段，则作业模板的**剧本**字段将不会进行验证，并且您必须启动作业模板以验证预期剧本的存在。
21.5.3. Git Refspec¶
**SCM Refspec** 字段指定更新应该从远程下载哪些额外的引用。 示例如下
refs/*:refs/remotes/origin/*：获取所有引用，包括远程的远程
refs/pull/*:refs/remotes/origin/pull/*（特定于 GitHub）：获取所有拉取请求的所有引用
refs/pull/62/head:refs/remotes/origin/pull/62/head：获取该 GitHub 拉取请求的引用
对于大型项目，您应该考虑在使用此处列出的第一个或第二个示例时对性能的影响。
SCM Refspec 参数会影响项目分支的可用性，并允许访问其他情况下无法访问的引用。以上示例允许用户提供来自 SCM 分支 的拉取请求，如果没有 SCM Refspec 字段，这是不可能的。
Ansible git 模块默认获取 refs/heads/*。这意味着如果 SCM Refspec 为空，项目的 branches 和 tags（以及其中的提交哈希）可以用作 SCM 分支。在 SCM Refspec 字段中指定的值会影响哪些 SCM 分支 字段可以用作覆盖。项目更新（任何类型）都会执行额外的 git fetch 命令从远程拉取该 refspec。
例如：你可以设置一个项目，允许使用第一个或第二个 refspec 示例进行分支覆盖 -> 在一个作业模板中使用它，该模板会提示输入 SCM 分支 -> 当创建一个新的拉取请求时，客户端可以启动作业模板，提供分支 pull/N/head -> 作业模板将针对提供的 GitGub 拉取请求引用运行。
有关 Ansible git 模块的更多信息，请参见 https://docs.ansible.org.cn/ansible/latest/modules/git_module.html.