优化大规模 Ansible 部署的最佳实践

Ansible 在配置管理和应用部署方面表现出色，但当部署扩展到数千个节点时——这在企业环境中是常见需求——性能调优变得至关重要。未经优化的 Ansible 运行可能导致数小时的执行时间、控制器资源耗尽和连接失败。

本指南概述了有效管理庞大资产清单所必需的关键架构策略和配置更改，重点关注最大限度地提高并行度、最小化网络开销和智能资源分配。实施这些实践是实现跨大规模基础设施（通常定义为 1,000 个以上主机）可靠、及时配置的关键。

1. 掌握执行并行度与策略

优化 Ansible 连接和管理并发任务的方式，是减少大型资产清单运行时间的头号因素。

使用 `forks` 控制并发性

forks 参数定义了 Ansible 控制器可以派生的并行进程工作者的数量。寻找最佳数量需要在控制器资源（CPU 和内存）与目标环境的连接限制之间取得平衡。

可操作的配置：

在 ansible.cfg 或通过命令行（-f 或 --forks）设置 forks。

[defaults]
forks = 200 ; 从保守开始，根据控制器监控进行调整

提示： 开始使用 100-200 个 forks 进行测试，并监控控制器的 CPU 利用率。如果 CPU 在等待主机时保持空闲，则增加 forks。如果 CPU 达到饱和或内存耗尽，则降低该数值。

选择正确的策略插件

Ansible 的默认执行策略是 linear（线性），这意味着任务必须在所有目标主机上完成后，才能进行 Playbook 中的下一个任务。对于数千个节点，单个慢速主机可能会成为整个运行的瓶颈。

对于大规模部署，请使用 free 策略。

Free 策略 (strategy = free)：
允许主机在完成任务后立即独立地通过 Playbook，而无需等待较慢的主机。这极大地提高了整体部署吞吐量。

# Playbook 示例定义
---
- hosts: all
  strategy: free
  tasks:
    - name: 确保服务正在运行
      ansible.builtin.service:
        name: httpd
        state: started

2. 利用事实缓存提高速度

事实收集（setup 模块）至关重要，但在大型部署中是资源密集型的，通常会消耗总运行时间的 10-20%。默认情况下，Ansible 收集事实后会将其丢弃。缓存这些事实可避免重复的网络调用。

使用外部缓存 (Redis 或 Memcached)

对于大规模部署，基于文件的缓存速度太慢且效率低下。请使用 Redis 或 Memcached 等外部高速缓存。

ansible.cfg 中的可操作配置：

[defaults]
gathering = smart
fact_caching = redis
fact_caching_timeout = 7200 ; 缓存事实 2 小时（以秒为单位）
fact_caching_prefix = ansible_facts

; 如果使用 Redis
fact_caching_connection = localhost:6379:0

最佳实践： 设置 gathering: smart。这会告诉 Ansible 仅在事实尚未被缓存或缓存被禁用的情况下才收集事实。此外，如果您知道只需要特定的事实（例如，网络接口），请使用 gather_subset 来最小化数据传输。

3. 优化连接和传输

在处理数千个并发 SSH 会话时，减少建立连接相关的开销至关重要。

SSH 流水线 (Pipelining)

流水线通过单个 SSH 连接执行多个 Ansible 命令，从而减少每个任务所需的网络操作次数。此功能必须启用。

SSH 连接重用 (ControlPersist)

对于类 Unix 目标，ControlMaster 和 ControlPersist 设置可防止 Ansible 为每个任务启动一个全新的 SSH 会话。它会保持控制套接字打开指定持续时间，允许后续任务使用现有连接。

ansible.cfg 中的可操作配置：

[ssh_connection]
pipelining = True

; 使用积极的连接重用（例如，30 分钟）
ssh_args = -C -o ControlMaster=auto -o ControlPersist=30m -o ServerAliveInterval=15

警告： Pipelining 要求目标节点具备 root 权限，以便通过 sudo 或 su 写入临时文件。如果您的配置使用了复杂的 sudo 设置，请确保兼容性。

Windows 优化 (WinRM)

针对 Windows 节点时，请确保 WinRM 已正确配置以进行扩展。增加 Windows 目标上的 max_connections 限制，并尽可能使用 Kerberos 认证，以获得比基本认证更好的安全性和性能。

4. 针对规模的资产清单管理

当处理数千个临时节点时，静态资产清单文件很快变得难以管理和不准确。动态资产清单是实现大规模部署的必要条件。

动态资产清单来源

利用针对您的云提供商（AWS EC2、Azure、Google Cloud）或 CMDB 系统的资产清单插件。动态资产清单可确保 Ansible 仅针对具有最新数据的活动主机。

# 示例：针对动态过滤的 AWS 资产清单运行
ansible-playbook -i aws_ec2.yml site.yml --limit 'tag_Environment_production'

智能定位和过滤

除非绝对必要，否则请避免对整个资产清单运行 Playbook (hosts: all)。使用精细的组、限制 (--limit) 和标签 (--tags) 来确保执行目标集最小化。

5. 架构考量和控制器规模确定

对于大规模部署，运行 Ansible 的环境必须进行适当的配置。

控制器规模确定

由于需要派生进程进行并行执行，Ansible 对控制器资源（主要是 CPU 和 RAM）高度依赖。

CPU： 与 forks 数量直接相关。一个经过高度优化的控制器每 50-100 个并发连接（取决于工作负载）需要 1 个 CPU 核心。
RAM： 每个 fork 都需要内存。复杂的任务（涉及 Python 库或大型数据结构的任务）需要每个 fork 消耗更多 RAM。
存储 I/O： 快速 SSD 存储至关重要，尤其是在依赖临时文件或本地事实缓存的情况下。

利用自动化平台

对于真正的企业规模和运营成熟度，请利用 Ansible 自动化平台 (AAP，前身为 AWX/Tower)。

AAP 提供：
* 作业调度和历史记录： 集中式日志记录和审计。
* 执行环境： 一致、可重现的运行时环境。
* 集群和扩展： 在多个工作节点上分配执行，以应对大规模并发需求，而不会使单个控制器过载。
* 凭证管理： 大规模安全处理密钥。

6. 提高效率的 Playbook 设计

即使基础设施经过优化，编写拙劣的 Playbook 也会抵消性能增益。

最小化事实收集

如果您使用了缓存事实（第 2 节），请在可能的情况下主动禁用冗余的事实收集：

- hosts: web_servers
  gather_facts: no # 禁用此 Play 的事实收集
  tasks:
    # ... 只运行不依赖于收集到的系统事实的任务

谨慎使用 `run_once` 和 `delegate_to`

必须顺序或集中运行的任务（例如，启动滚动部署、更新负载均衡器）应通过 run_once: true 和 delegate_to: management_node 来处理。当只需要一个主机执行操作时，这可以避免浪费并行性。

首选批量操作

只要有可能，请使用原生支持批量操作的模块（例如，接受包列表的 apt 或 yum 等包管理器），而不是使用 loop 或 with_items 针对单独的 package 任务迭代大型列表。

# 优：单个任务，包列表
- name: 安装必要的依赖项
  ansible.builtin.package:
    name:
      - nginx
      - python3-pip
      - firewall
    state: present

总结

优化大规模 Ansible 部署是一个迭代过程，需要仔细调整控制器环境和部署配置。最具影响力的更改包括启用连接持久性 (ControlPersist)、实施事实缓存（最好是 Redis），以及根据控制器资源监控策略性地增加并行度 (forks)。通过将执行策略转为 free 并利用动态资产清单，组织可以确保其配置管理可靠地扩展到标准限制之外。