在日常的自动化运维工作中，我们经常会使用Ansible来批量管理服务器。但大家有没有遇到过这样的烦恼：脚本跑得好好的，突然因为网络抖动了一下，某个任务就失败了，导致整个剧本（Playbook）中断。尤其是在管理云上服务器或跨机房设备时，网络不稳定几乎是个绕不开的坎。今天，我们就来好好聊一聊，如何让Ansible在面对“任性”的网络时，变得更加坚韧和智能，学会“失败了再来一次”。

一、为什么需要任务重试？理解背后的场景

想象一下，你正在用Ansible给几十台服务器安装一个重要的安全更新包。这个操作需要从中央仓库下载软件。如果其中一两台服务器在下载时，刚好遇到网络闪断，整个安装流程就会戛然而止。你不得不手动找出失败的主机，重新运行剧本，或者写更复杂的逻辑来处理。

这就是任务重试机制要解决的核心问题：应对暂时性、可恢复的故障。这类故障通常不是程序或配置本身有错误，而是由外部环境的不稳定因素造成的，比如：

  • 网络连接短暂中断：SSH连接超时、HTTP请求失败。
  • 远程服务未就绪：比如你重启了一个Web服务，紧接着去检查它是否健康，但服务启动需要几秒钟，第一次检查时它可能还没准备好。
  • 资源临时不可用：例如访问一个偶尔繁忙的API，或者等待一个分布式锁。
  • 依赖服务短暂异常：比如数据库连接池瞬间占满。

对于这类“小毛病”，最直接有效的策略就是“等一等，再试一次”。Ansible内置和社区提供了一些非常棒的工具来帮助我们实现这一点。

二、Ansible内置的“再来一次”法宝：until循环与retries

Ansible自己就带了一个简单却强大的重试工具组合：until条件循环，配合 delay（延迟）和 retries（重试次数）。它特别适合用来“等待”某个条件成立。

技术栈声明：本文所有示例均基于 Ansible Core 2.14+ 及 Python 3.8+ 环境。

让我们看一个经典的例子：等待一个Web服务启动并返回正确的状态码。

# 示例：使用 until 循环等待服务健康检查通过
- name: 等待应用服务完全启动并健康
  ansible.builtin.uri: # 使用uri模块发起HTTP请求
    url: "http://{{ inventory_hostname }}:8080/health"
    method: GET
    status_code: 200 # 期望的HTTP状态码是200
    timeout: 5 # 请求超时时间5秒
  register: health_check_result # 将模块执行结果注册到变量
  until: health_check_result.status == 200 # 循环条件：状态码等于200
  retries: 10 # 最多重试10次
  delay: 3 # 每次重试之间间隔3秒
  ignore_errors: yes # 在循环过程中，忽略单次失败的错误，避免剧本中断

代码注释说明：

  • ansible.builtin.uri: 这是Ansible用于处理HTTP/HTTPS请求的核心模块。
  • register: 关键字，用于将这次任务执行的结果（包括返回值、状态等）保存到一个变量（这里是health_check_result）中，供后续任务或条件判断使用。
  • until: 这是实现重试逻辑的关键。任务会一直重复执行，直到这里定义的条件被满足（返回True）。
  • retries: 定义最多尝试多少次。总执行次数 = retries + 1（初始的那一次）。
  • delay: 定义每次重试之间等待多少秒，避免过于频繁的请求。
  • ignore_errors: yes: 这个很重要！在until循环中，每次尝试都可能失败（比如网络超时），这个设置可以确保单次失败不会让整个任务标记为失败，从而中断循环。只有当重试次数用尽，条件仍未满足时，任务才会最终失败。

这个组合拳非常直观，但它主要适用于需要主动轮询检查结果的场景。对于更通用的任务失败重试（比如一个普通的软件包安装命令失败），我们需要更强大的武器。

三、更强大的守护者：ansible.builtin.retry 模块

在较新的Ansible版本中，核心模块集合引入了一个名为 ansible.builtin.retry 的模块。它允许你将任何一个任务包装在重试逻辑里，功能更通用、更灵活。

它的工作原理是：先定义一个“重试器”，规定好重试次数、延迟策略等；然后，让需要保护的任务在重试器的作用下运行。

下面我们模拟一个场景：通过SSH连接执行一个命令，该命令依赖外部网络，可能因网络波动失败。

# 示例：使用 retry 模块保护一个可能因网络失败的命令任务
- name: 从外部网络获取关键配置（受重试保护）
  block: # 使用block将多个任务组织成一个逻辑块
    - name: 执行获取配置的命令
      ansible.builtin.shell: |
        curl -sSf https://config-server.example.com/global-settings.json -o /tmp/settings.json
        # 模拟一个可能因网络超时而失败的curl命令
      args:
        executable: /bin/bash
      register: cmd_result
      # 注意：这个任务本身没有错误处理，失败会抛出异常。

  rescue: # 如果block中的任何任务失败，则执行rescue块
    - name: 记录获取配置失败
      ansible.builtin.debug:
        msg: "从外部获取配置失败，将使用本地备用配置。"

    - name: 使用本地备用配置文件
      ansible.builtin.copy:
        src: "./local_fallback_settings.json"
        dest: "/tmp/settings.json"

  always: # 无论block成功还是失败，最后都会执行always块
    - name: 确保配置存在（最终检查）
      ansible.builtin.stat:
        path: /tmp/settings.json
      register: config_stat

# 但是，上面的block/rescue结构处理的是最终失败后的降级方案。
# 如果我们希望在失败发生时就立即重试，而不是走到rescue，就需要 retry 模块。
- name: 重试获取配置直到成功（最多3次）
  retry: # 这是重试模块，它控制其下方任务的重试行为
    attempts: 3 # 最多尝试3次
    delay: 5 # 基础延迟5秒
    # 还可以设置 backoff_factor (退避因子)，让延迟时间指数增长，例如 delay: 2， backoff_factor: 2， 则延迟为 2, 4, 8秒...
  ansible.builtin.shell: |
    curl -sSf https://config-server.example.com/global-settings.json -o /tmp/settings.json &&
    echo "Configuration fetched successfully."

代码注释与关联技术详解：

  • block, rescue, always: 这是Ansible的错误处理机制，类似于编程中的try-catch-finally。它擅长处理最终失败后的补救或清理，但不擅长自动重试。retry模块则填补了“自动重试”的空白。
  • ansible.builtin.retry: 这是一个任务包装器，不是一个独立执行的任务。它必须直接放在需要重试的任务之上，中间不能有别的任务。它通过attempts和delay等参数控制重试行为。
  • backoff_factor: 这是一个高级参数，用于实现“指数退避”策略。比如delay: 2, backoff_factor: 1.5，那么重试延迟将是：第1次重试等2秒，第2次等3秒（21.5），第3次等4.5秒（31.5）。这种策略能有效避免在服务恢复期造成“惊群”式的重复请求。

retry模块让重试逻辑变得清晰、独立，并且可以应用到几乎所有任务类型上，是处理网络等暂时性故障的利器。

四、组合策略与高级玩法：让重试更智能

在实际生产中，我们很少只使用单一策略。通常会将内置重试、错误处理块和条件判断组合起来，形成更健壮的逻辑。

场景：部署一个微服务，包括拉取镜像、启动容器、等待健康检查。

# 示例：组合使用多种机制完成一个容器的部署
- name: 部署后端服务容器
  hosts: app_servers
  tasks:
    - name: 从镜像仓库拉取最新镜像（可能因网络慢而失败）
      community.docker.docker_image: # 使用Docker社区模块
        name: "{{ service_image }}"
        tag: "{{ service_version }}"
        source: pull
      register: pull_result
      retry:
        attempts: 3
        delay: 10
      # 即使重试失败，我们也希望继续，因为可能本地有旧镜像
      ignore_errors: yes

    - name: 停止并移除旧容器
      community.docker.docker_container:
        name: "my_backend_service"
        state: absent
      # 这个任务通常很稳定，不需要重试

    - name: 启动新容器
      community.docker.docker_container:
        name: "my_backend_service"
        image: "{{ service_image }}:{{ service_version }}"
        state: started
        restart_policy: always
        ports:
          - "8080:8080"
      # 启动命令本身很快，一般不需要重试

    - name: 等待服务健康端点就绪（使用until循环）
      ansible.builtin.uri:
        url: "http://localhost:8080/actuator/health"
        return_content: yes
        status_code: 200
        body_format: json
      register: health_result
      until: >
        health_result.status == 200 and
        health_result.json.status == 'UP' # 检查返回的JSON内容
      retries: 12
      delay: 5
      # 这里没有ignore_errors，因为until循环本身会处理

    - name: 记录部署结果
      ansible.builtin.debug:
        msg: "服务 {{ inventory_hostname }} 部署成功且健康！"

这个例子展示了如何根据任务的不同性质，混合搭配策略：

  1. 拉取镜像：网络密集型操作，使用retry进行通用重试，并用ignore_errors防止因最终拉取失败而阻塞后续流程（也许本地有可用镜像）。
  2. 启动容器：本地操作，通常很稳定，不设重试。
  3. 健康检查：典型的“等待条件成立”场景，使用until循环最为合适。

五、应用场景、优缺点与注意事项

应用场景总结：

  • 服务部署与启动：等待服务端口监听、健康检查通过。
  • 软件包管理：在偶尔不稳定的仓库中安装或更新软件。
  • 云资源操作：创建云主机、存储桶等，等待云API返回成功状态。
  • 配置管理：从外部配置中心拉取配置信息。
  • 任何涉及网络I/O的操作：文件下载、API调用、数据库连接等。

技术优缺点分析：

  • 优点：
    • 显著提升鲁棒性：能自动消化掉大部分临时性故障，减少人工干预。
    • 配置简单直观：until和retry的语法都很容易理解和使用。
    • 策略灵活：可以组合使用，针对不同任务精细化配置重试行为（如次数、延迟、退避）。
  • 缺点与风险：
    • 可能掩盖真正问题：如果配置了过高的重试次数和ignore_errors，一个真正的配置错误可能会被反复重试很久才报错，浪费时间和资源。
    • 延长失败反馈时间：对于注定失败的任务，重试机制会延迟最终错误的出现。
    • 增加负载：如果目标服务已经瘫痪，大量主机的重试请求可能会形成“重试风暴”，加剧服务压力。

重要注意事项：

  1. 明确重试条件：只对暂时性故障进行重试。对于权限错误、语法错误、资源不足等永久性错误，重试没有意义，应立即失败。
  2. 合理设置重试参数：retries/attempts 和 delay 需要根据具体场景调整。网络操作可以多试几次、延迟长一点；本地操作可以少试或不试。
  3. 善用ignore_errors：在until循环中通常需要它；在普通任务的重试中，要谨慎使用，想清楚最终失败是否可以被接受。
  4. 结合错误处理：将retry与block/rescue结合。retry负责“尝试恢复”，rescue负责“最终补救”。
  5. 监控与告警：对于重试后依然失败的任务，一定要有清晰的日志输出和告警机制，以便运维人员及时跟进。

六、总结

面对不可靠的网络，Ansible的任务重试机制就像给自动化脚本穿上了一层“防弹衣”。until循环是应对“等待”场景的精准工具，而retry模块则为通用任务提供了强大的自动重试保护。通过理解它们的原理，并巧妙地与错误处理块（block/rescue）结合，我们可以设计出既能应对环境波动，又能快速暴露根本问题的健壮Playbook。

记住核心思想：重试是为了容错，而不是隐藏错误。 合理的重试策略能让你的自动化工作流在复杂多变的IT环境中从容不迫，稳步前行。下次当你的Ansible任务因为网络“抖了一下”而失败时，不妨试试给它一个“再来一次”的机会。