13：实施任务控制-3 管理Play中的任务错误

type

status

date

slug

summary

管理 Ansible Playbook：任务失败和条件执行的最佳实践

在使用 Ansible 进行自动化管理时，处理任务失败和根据条件执行其他任务是至关重要的。本文将探讨如何在 Ansible Playbook 中实现这些功能，确保我们的自动化流程更加健壮和灵活。

忽略任务失败

有时，某些任务可能会失败，但我们希望 Playbook 继续执行。可以使用 ignore_errors 选项来实现这一点。下面是一个示例，展示如何在 Ansible Playbook 中忽略任务失败：

在这个示例中，即使 notapkg 安装失败，Playbook 仍会继续执行后续任务。

强制执行处理程序

在 Ansible 中，可以强制在任务失败后执行特定的处理程序。使用 force_handlers 选项可以确保即使某个任务失败，仍然会调用已通知的处理程序。

在此示例中，虽然第二个任务由于包不存在而失败，但仍然会触发 Restart the database 处理程序。

指定任务失败条件

可以使用 failed_when 条件来定义任务的失败条件。这允许我们在任务失败时根据命令输出自定义错误消息。

`failed_when` 的概念

failed_when 是 Ansible 中用于控制任务失败条件的指令。它允许你根据特定的条件判断任务是否应被视为失败，而不仅仅依赖于模块的返回代码。

示例代码

下面是一个使用 failed_when 的示例：

逻辑分析

执行用户创建脚本：

该任务运行 /usr/local/bin/create_users.sh 脚本，并将结果存储在 command_result 变量中。

判断失败条件：

如果输出中包含字符串 "Password missing"，failed_when 条件为真，任务将被视为失败。

这意味着用户没有成功创建。

报告失败：

Report script failure 任务仅在 command_result.stdout 包含 "Password missing" 的情况下执行，表示用户创建失败。

没有使用 `failed_when` 的情况

如果我们不使用 failed_when，代码可能如下所示：

在这种情况下，任务的成功与否仅依赖于脚本的返回码：

脚本执行成功（返回码为 0）：

任务将被视为成功，即使输出中包含 "Password missing"。

此时无法确认用户是否真正创建。

脚本执行失败（返回码非 0）：

任务将被视为失败。

总结

使用 failed_when 提供了一种灵活的方法来判断任务是否失败，基于任务输出的内容。

如果不使用 failed_when，任务的成功与否将完全依赖于执行模块的返回码，可能导致无法准确判断用户创建的状态。

通过在 Ansible 中使用 failed_when，你可以根据实际情况更加灵活地管理任务的执行逻辑，确保自动化脚本的可靠性和有效性。

任务改变状态的控制

通过 changed_when 选项，我们可以控制任务的改变状态。以下示例演示了如何验证配置语法而不实际更改任何内容：

在这个示例中，httpd -t 命令用于验证配置，但不会影响主机的状态，因此 changed_when 被设置为 false。

使用块（Block）和异常处理

Ansible 的 block 功能允许将多个任务组合在一起，并提供 rescue 和 always 选项来处理错误。以下是一个示例：

在这个例子中，无论数据库升级是否成功，都会重启数据库。

总结

通过使用 Ansible 的 ignore_errors、force_handlers、failed_when 和 block 等功能，我们可以更加灵活和有效地管理任务失败和条件执行。这些技术使得我们的 Ansible Playbook 在面对复杂的操作时更加可靠。

任务失败控制实验 - Ansible Playbook

实验目标

我们将通过实验展示如何使用 ignore_errors、block、rescue、always 以及 failed_when 等 Ansible 选项来控制任务的失败处理和条件执行逻辑。

1. 检查 Inventory 文件

首先，运行以下命令查看 Inventory 配置：

Inventory 文件内容：

2. 创建初始 Playbook 文件

使用以下代码创建 playbook.yml，然后通过 vim playbook.yml 打开并编辑文件。

3. 运行 Playbook，观察行为

执行 Playbook，查看结果：

由于 http 不是有效的软件包名，任务会失败，后续的 db_package 任务也不会执行。

4. 添加 `ignore_errors: yes` 参数

在第一个任务中添加 ignore_errors: yes，使 Playbook 在任务失败时继续执行：

再次运行 Playbook，尽管 Install {{ web_package }} package 任务失败，但 db_package 任务将被执行。

5. 使用 `block`、`rescue` 和 `always` 控制流程

进一步优化代码，使用 block、rescue 和 always 控制任务执行流：

6. 运行 Playbook，观察行为

执行 Playbook，查看在 web_package 任务失败后 rescue 和 always 任务的执行情况：

rescue：Install {{ db_package }} package 在 web_package 失败时被执行。

always：无论任务成功与否，Start {{ db_service }} server 都会执行。

7. 修改 `web_package` 为正确的 `httpd`

将 web_package 修改为 httpd，使任务成功：

再次运行 Playbook，观察所有任务的执行情况。

8. 添加 `failed_when` 条件

将 failed_when 条件添加到 block 中的第一个任务中，以控制任务失败的判断条件。

9. 运行并观察 `failed_when` 行为

再次运行 Playbook，观察 failed_when 条件的效果。尽管 httpd 包存在，但由于 failed_when 条件为真，任务会被视为失败，从而触发 rescue 和 always 块。

总结

ignore_errors：让任务在失败时继续执行，但不触发错误处理。

block-rescue-always：提供任务执行的控制逻辑，适合在特定任务失败时执行补救操作。

failed_when：通过条件判断任务是否失败，灵活控制执行流程。

通过这些示例，展示了 Ansible 中不同的失败控制选项如何帮助我们更灵活地管理 Playbook 的执行逻辑。