Ansible滚动更新的核心是通过serial参数控制批次大小，结合负载均衡实现零停机更新，并利用roles、tags、block/rescue等机制保障可维护性与失败处理能力。

Ansible 实现滚动更新的核心，是控制更新节奏、保障服务连续性，而不是一次性全量变更。它不依赖外部调度器，而是通过内置机制在 playbook 层面精确调度主机批次和执行顺序。

用 serial 控制批次大小

这是最直接有效的滚动更新控制方式。通过 serial 参数，你可以指定每次只对多少台主机执行整个 playbook 流程——不是单个任务，而是从 gathering facts 到所有 tasks 再到 handlers 的完整轮次。

• 设为数字（如 serial: 2）：每次处理 2 台，成功后再处理下一批
• 设为百分比（如 serial: "25%"）：按目标主机总数动态计算批次，适合主机数量波动的环境
• 若某一批中任意主机失败，Ansible 默认中止整个 playbook，避免部分更新导致状态不一致

配合负载均衡实现零停机

滚动更新真正发挥价值，需要与负载均衡器协同。典型流程是“摘流—更新—验证—加流”，Ansible 可驱动全过程：

• 先调用 HAProxy、Nginx 或云厂商 LB 模块（如 haproxy 或 aws_elb），将当前批次主机从后端池移除
• 再执行应用部署、配置更新、服务重启等操作
• 接着用 wait_for 或自定义健康检查任务确认新服务已就绪
• 最后将该主机重新加入负载均衡池，流量逐步恢复

结合角色与标签提升可维护性

大型系统常需分层更新（如先升 MON，再升 OSD，最后升 MGR）。这时不应靠多个独立 playbook 管理，而应统一在一个 rolling_update.yml 中，用 tags 和 roles 隔离逻辑：

• 每个组件（mon、osd、mgr）封装为独立 role，包含自己的变量、任务和校验逻辑
• 主 playbook 中按顺序 include role，并为每段加上明确 tag，例如 --tags=mons
• 配合 serial 使用，确保同类节点按批滚动，跨类型节点按序推进

失败处理与可观测性设计

滚动更新不是“跑完就结束”，而是要能快速定位、隔离、回退：

• 在关键任务后添加 assert 或 shell 命令验证（如 curl -f http://localhost/health）
• 利用 ignore_errors: true + failed_when 精确控制哪些失败可跳过、哪些必须中断
• 通过 block + rescue 定义异常路径，比如自动触发备份还原或配置回滚
• 用 notify 触发 handler 发送 Slack/邮件通知，附带当前批次、耗时、失败主机列表