Ansible 并发与生产最佳实践

Ansible 能快速批量变更，也会快速放大错误。生产使用的关键不是把 forks 调得越大越好，而是控制影响范围、确认幂等、限制失败扩散并保留证据。

一、并发由哪些因素决定

forks：控制节点可同时运行的任务进程数。
serial：一个 Play 每批处理多少目标主机。
strategy：主机是否按线性节奏推进，或各自尽快执行。
throttle：对某个任务、Block 或角色单独限制并发。
async 与 poll：长任务的异步执行和轮询方式。

高并发会增加 SSH 连接、控制节点 CPU/内存、目标仓库、API、数据库和负载均衡器压力。并发上限应通过测试确定。

二、生产灰度模板

- name: Rolling change
  hosts: app_servers
  serial:
    - 1
    - 20%
    - 50%
  max_fail_percentage: 10
  any_errors_fatal: true
  become: true

  tasks:
    - name: Validate preconditions
      ansible.builtin.assert:
        that:
          - ansible_facts.os_family == "RedHat"

    - name: Deploy configuration
      ansible.builtin.template:
        src: app.conf.j2
        dest: /etc/app/app.conf
        owner: root
        group: root
        mode: "0640"
        backup: true
      notify: Restart app

  handlers:
    - name: Restart app
      ansible.builtin.service:
        name: app
        state: restarted

先处理 1 台金丝雀，再逐步扩大批次。每批完成后执行健康检查，不要只依据模块返回 changed 判断业务成功。

三、幂等与检查模式

优先使用内置模块，不用无条件执行的 shell 或 command。
为确需命令的任务设置 creates、removes、changed_when 和 failed_when。
使用 --check --diff 预览，但要知道并非所有模块都完整支持检查模式。
同一 Playbook 连续运行两次，第二次应尽量返回无变化。

ansible-playbook site.yml --syntax-check
ansible-playbook site.yml --check --diff --limit canary
ansible-playbook site.yml --limit canary

四、Inventory 与变量治理

按环境、业务和角色分组，避免复制多份清单。变量优先级复杂，敏感变量应使用 Vault 或外部密钥系统，不能将明文凭据提交到仓库。

动态清单和 CMDB 数据要有缓存、超时和来源校验。执行前输出实际目标列表：

ansible-inventory --graph
ansible all --list-hosts --limit 'prod:&app_servers'

五、失败控制与回退

变更前验证磁盘、依赖、版本、备份和维护窗口。
对负载均衡摘除、配置变更、服务重启和重新加入分别设检查点。
用 block、rescue、always 组织异常处理，但不要假装所有变更都可自动回滚。
数据库迁移、证书替换等不可逆步骤应独立审批。
保存执行日志、Playbook 版本、Inventory 快照和发起人。

六、性能调优顺序

先观察控制节点 CPU、内存、文件句柄、网络和目标系统负载，再逐步调整 forks。启用 SSH 连接复用、Fact 缓存或流水线前，要理解安全边界与目标系统兼容性。不要在生产首次尝试激进参数。

七、验收标准

--syntax-check 与代码审查通过；
金丝雀和小批次验证成功；
第二次运行无无意义变更；
业务健康检查、监控和日志正常；
失败主机列表、失败原因和人工处理项清晰；
回退步骤在相同环境验证过。

Ansible并发与生产最佳实践