Ansible滚动升级需构建可控闭环流程：用serial控制批次、联动LB摘/加流、block-rescue封装原子操作与回退、delegate_to+run_once保障跨节点协同。
Linux 下用 Ansible 实现服务滚动升级，关键不是“逐台跑命令”，而是构建一个可控、可验、可退的闭环流程：控制更新节奏、隔离流量、验证状态、再恢复服务。整个过程不依赖外部调度器，全由 Ansible 原生命令驱动。
用 serial 精确控制更新批次
serial 参数写在 play 顶层，决定每次只对多少台节点执行当前 play 的全部任务：
- serial: 1：严格单节点更新，适合数据库主库或支付类核心服务，每台完成验证后再动下一台
- serial: "25%"：按总节点数自动计算批次（如 16 台 → 每批 4 台），兼顾效率与冗余能力
- serial: [1, 3, 5]：阶梯式推进——首台做兼容性验证，中间批量过渡，最后并行收尾
联动负载均衡器动态摘流与加流
滚动升级成败取决于能否安全切断和恢复流量。以 HAProxy 为例：
- 更新前调用
haproxy模块或uri模块，向 HAProxy Stats API 发送禁用指令（如POST /disable?backend=app&server=web01） - 插入
pause: seconds=10，确保已有连接自然断开或超时 - 更新完成后再次启用节点，并用
wait_for: port=8080 timeout=30或uri模块检查健康接口（如GET /health返回 200）
封装单节点原子操作与失败回退
每台节点的操作应是一套完整闭环，避免半途而废：
- 用
block包裹“停服务→备份旧文件→部署新包→启动服务→验证响应”全流程 - 配套
rescue段，在任意步骤失败时自动还原备份配置或拉起旧版本服务 - 部署前用
copy: src=xxx backup=yes自动备份关键配置和二进制文件 - 验证阶段不止看端口通，建议解析健康接口返回内容：
failed_when: health.status != 'ok'
跨节点协同需明确委托与唯一执行
涉及主从切换、全局状态变更等场景，必须防止多节点并发冲突：
- 主库执行备份操作时，加
delegate_to: primary_db并设run_once: true - 备库执行提升命令时，同样用
delegate_to: standby_db，确保动作落在指定节点 - 所有决策类任务（如修改集群配置、触发选举）都应加
run_once: true，避免重复触发
