识别并修复慢速Ansible剧本中的瓶颈

慢速的Ansible剧本令人沮丧，因为延迟很少集中在某个明显的位置。一次运行可能花费几秒钟收集事实，几秒钟建立SSH连接，然后几分钟逐个主机复制文件。如果你只是猜测，通常你会调优错误的地方。

首先测量时间花在哪里。然后优先修复最大的延迟源。在小型环境中，这可能是每次运行包管理器的单个shell任务。在大型环境中，通常是连接建立、事实收集、低forks值，或者一个比预期更串行化工作的剧本。

理解Ansible性能指标

在深入具体的优化技术之前，理解如何测量和解读Ansible的性能至关重要。Ansible提供了内置的时间信息，对诊断非常有价值。

在详细日志之前使用时间输出

非常详细的输出可以帮助解决连接问题，但对于性能工作来说过于嘈杂。更清晰的初步方法是使用profile_tasks回调，它在运行结束时显示任务持续时间。

在ansible.cfg中：

[defaults]
callbacks_enabled = profile_tasks

然后正常运行剧本：

ansible-playbook my_playbook.yml

首先查看最慢的任务。如果一个任务占用了大部分运行时间，不要花整个上午争论forks。

控制输出详细程度

当你需要查看SSH细节、模块传输行为、重试或解释器发现时，使用-vvv。对于常规计时，它可能会在数页日志输出中隐藏信号。

常见瓶颈及优化策略

多种因素可能导致Ansible剧本变慢。在这里，我们将探讨常见瓶颈并提供可行的解决策略。

1. 过度的事实收集

默认情况下，Ansible在每个剧本开始时从受管主机收集事实（系统信息）。虽然有用，但这可能耗时，尤其是在大量主机或慢速网络上。如果你的剧本不需要所有收集的事实，可以禁用或限制事实收集。

禁用事实收集

要完全禁用某个剧本的事实收集，使用gather_facts: no指令：

- name: My Playbook
  hosts: webservers
  gather_facts: no
  tasks:
    - name: Ensure Apache is installed
      apt: name=apache2 state=present

限制事实收集

如果你需要一些事实但不是全部，可以使用gather_subset指定要收集的事实。

- name: My Playbook
  hosts: webservers
  gather_facts: yes
  gather_subset:
    - '!all'
    - '!any'
    - hardware
    - network
  tasks:
    - name: Use network facts
      debug: var=ansible_default_ipv4.address

缓存事实

对于事实不频繁变化的环境，缓存它们可以显著加快后续剧本运行。Ansible支持多种事实缓存插件（例如jsonfile、redis、memcached）。

要启用事实缓存，在ansible.cfg文件中配置：

[defaults]
fact_caching = jsonfile
fact_caching_connection = /path/to/ansible/facts_cache
fact_caching_timeout = 86400 # 缓存24小时

然后，你的剧本将自动使用缓存的事实（如果可用）。

2. 低效的任务执行

某些任务可能天生缓慢，或者执行方式低效。

并行执行（Forking）

Ansible的默认行为是在一个剧本中顺序执行主机上的任务。你可以增加Ansible用于同时管理主机的并行进程数（forks）。这由ansible.cfg中的forks设置或通过-f命令行选项控制。

ansible.cfg：

[defaults]
forks = 10

命令行：

ansible-playbook my_playbook.yml -f 10

提示： 从适中的forks数开始，逐步增加，同时监控控制节点、网络和目标服务。更多的forks可以加快部署，但也可能压垮包仓库、负载均衡器或数据库迁移步骤。

幂等性和状态管理

确保你的任务是幂等的。这意味着多次运行任务应该与运行一次效果相同。Ansible模块通常设计为幂等的，但自定义脚本或命令可能不是。任务中的低效检查也会增加开销。

例如，不要运行检查服务是否运行然后启动它的命令，而是使用专用的service模块：

低效：

- name: Start service (inefficient check)
  command: systemctl start my_service.service || true
  when: "'inactive' in service_status.stdout"
  register: service_status
  changed_when: false # 此任务不改变状态

高效（使用service模块）：

- name: Ensure my_service is running
  service:
    name: my_service
    state: started

对长时间运行的操作使用`async`和`poll`

对于可能需要很长时间完成的任务（例如包升级、数据库迁移），使用Ansible的async和poll指令可以防止剧本挂起。

async：指定任务在后台运行的最大时间。
poll：指定Ansible检查异步任务状态的频率。

- name: Perform a long-running operation
  command: /usr/local/bin/long_script.sh
  async: 3600 # 最多运行1小时
  poll: 60    # 每60秒检查状态

3. 连接优化

Ansible连接到受管节点的方式对性能起着关键作用。

SSH连接复用

SSH复用（ControlMaster）允许多个SSH会话共享一个网络连接。这可以显著加快后续到同一主机的连接。

在ansible.cfg中启用：

[ssh_connection]
control_master = auto
control_path = ~/.ansible/cp/ansible-%%r@%%h:%%p
control_persist = 600 # 保持控制连接打开10分钟

SSH重试和超时

调整SSH连接参数可以防止主机暂时不可用时出现不必要的延迟。

[ssh_connection]
sf_retries = 3
sf_delay = 1
ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o ConnectionAttempts=5 -o ConnectTimeout=10

使用`pipelining`

Pipelining允许Ansible直接在远程主机上执行命令，而无需为每个命令创建新的SSH会话。这可以显著减少许多任务的开销。

在ansible.cfg中启用：

[ssh_connection]
pipelining = True

警告： Pipelining可能与某些权限提升设置冲突，尤其是在旧发行版上为sudo启用了requiretty时。请使用生产剧本使用的相同become路径进行测试。

4. 优化剧本结构和逻辑

有时，剧本的编写方式可能是缓慢的根源。

使用`delegate_to`和`run_once`

如果某个任务只需要在一个主机上执行但影响多个其他主机（例如重启负载均衡器），使用delegate_to和run_once高效执行。

- name: Restart load balancer
  service: name=haproxy state=restarted
  delegate_to: lb_server_1
  run_once: true

策略性地使用Roles和Includes

虽然roles和includes有助于组织，但深度嵌套或结构低效的includes可能会增加少量开销。确保你的角色依赖和include逻辑清晰。

`serial`关键字

serial关键字限制在一个剧本中同时操作的主机数量。虽然通常用于受控发布，但如果设置得太低，也可能成为性能瓶颈。

- name: Deploy application to a subset of servers
  hosts: appservers
  serial: 2 # 一次只在2个主机上运行
  tasks:
    - name: Update application code
      copy: src=app/ dest=/opt/app/

如果你不是有意限制并行性，确保serial未设置或设置为足够高的数字。

修复慢速任务，而不仅仅是慢速传输

连接调优在剧本包含许多短任务时有所帮助。它不能修复每次做太多工作的任务。

一个常见的例子是使用shell运行包命令：

- name: Install nginx with shell
  shell: apt-get update && apt-get install -y nginx

这个任务对于Ansible来说很难推理。它可能每次报告已更改，每次运行更新包元数据，并且给你更少的结构化失败信息。优先使用理解状态的模块：

- name: Refresh apt cache when needed
  apt:
    update_cache: true
    cache_valid_time: 3600

- name: Install nginx
  apt:
    name: nginx
    state: present

同样的想法适用于文件部署。通过copy模块复制包含数百个小文件的大目录可能很慢，因为Ansible逐个检查和传输文件。对于应用程序发布，可能更快的方法是构建一次工件，上传归档文件，然后在目标上解压：

- name: Upload release artifact
  copy:
    src: dist/app.tar.gz
    dest: /tmp/app.tar.gz

- name: Unpack release
  unarchive:
    src: /tmp/app.tar.gz
    dest: /opt/app
    remote_src: true

这并不总是正确的设计，但这是正确的问题：你是否要求Ansible同步数千个微小的决策，而一个工件会更清晰？

检查库存和变量工作

动态库存可能是另一个隐藏的延迟。如果每次剧本运行都调用云API、等待分页并重建整个主机列表，那么剧本可能在第一个任务开始之前就感觉缓慢。当你的插件支持时，缓存库存数据，并保持主机模式狭窄。针对all运行Web部署，然后使用when条件跳过大多数主机，会浪费时间。

变量加载也可能变得混乱。大型group_vars/all.yml文件、昂贵的查找和重复的模板渲染可能会累积。如果查找访问了密钥管理器或HTTP端点，将结果存储在每个剧本一次的变量中，而不是在许多任务中调用它。

分析工具和技术

除了Ansible本身的详细输出外，专门的分析可以提供更深入的见解。

`ansible-playbook --syntax-check`

此命令检查你的剧本是否存在语法错误，但不执行它。这是在完整运行前快速验证剧本结构的方法。

记录Ansible事件

Ansible可以将其执行事件记录到文件中，然后进行分析。这对于长时间运行的剧本或审计特别有用。

在ansible.cfg中配置事件日志：

[defaults]
log_path = /var/log/ansible.log

自定义回调插件

对于高级分析，你可以编写自定义回调插件来捕获特定指标或创建关于剧本执行的自定义报告。

对等待使用Async，而不是对所有事情

一些剧本时间是真正的等待：服务重启、包构建、云实例准备就绪或数据库迁移（合法需要几分钟）。如果这些任务不需要阻塞所有主机同步，Ansible的async和poll可以提供帮助。

- name: Start long-running report generation
  command: /opt/tools/build-report
  async: 1800
  poll: 0
  register: report_job

- name: Check report job
  async_status:
    jid: "{{ report_job.ansible_job_id }}"
  register: report_status
  until: report_status.finished
  retries: 60
  delay: 10

谨慎使用。Async不是使不安全任务并行的捷径。如果十台主机同时启动数据库迁移，剧本可能更快完成，但仍然会破坏环境。Async最适合独立的工作，其中目标可以安全地继续，而Ansible稍后检查。

从用户的角度衡量

一个剧本在技术上可以更快，但如果操作员等待太久才能看到有用的反馈，仍然会感觉缓慢。将大型部署分成具有清晰任务名称的阶段：预检检查、工件上传、服务更新、健康检查、清理。当一个阶段缓慢时，分析输出和阅读终端的人类都能理解时间花在了哪里。

这也有助于回滚决策。如果剧本在第一次健康检查之前花费了12分钟，你可能发现失败得太晚。一个检查磁盘空间、包仓库访问和服务凭据的小型预检任务可以节省比减少SSH设置一秒钟更多的时间。

最好的Ansible性能工作在好的方面是无聊的：启用任务计时，找到最慢的步骤，改变一件事，然后再次测量。仅在你不需要事实时禁用它们。仅当目标和依赖项能够处理并行性时增加forks。用状态感知模块替换嘈杂的shell命令。在确认连接开销确实是问题的一部分后，使用SSH复用和pipelining。

这种纪律使剧本保持可读性，同时使其更快。一个快速完成但没人理解的部署只是明天更短进度条的故障。