Ansible生产环境补丁执行顺序及inventory分组逻辑优化咨询

核心实现思路 #

业内针对这类有依赖关系、高可用约束的补丁更新场景，统一采用保留原有业务分组不变 + 运行时动态分组 + 多阶段依赖校验的方案，完全不需要额外维护静态补丁分组，也无需为所有主机逐一配置标签，仅需为少量有特殊依赖的主机标记属性即可。 #

第一步：优化Inventory配置（仅加属性不拆分组） #

完全保留你原有的按业务角色划分的inventory结构，仅给有SQL依赖的web服务器新增标记属性，无需修改其他配置：

---
all:
  dcs:
    hosts:
      domaincontroller1
      domaincontroller2
  dbs:
    hosts:
      sql1
      sql2
  webservers:
    hosts:
      websrv1:
        sql_dependent: true # 仅标记有SQL依赖的主机，无需单独创建host_vars文件
      websrv2:
      websrv3:
        sql_dependent: true
      websrv4:

第二步：Playbook实现（含动态分组+分阶段执行） #

playbook运行时自动生成所需的临时补丁分组，严格按照高可用、依赖约束分阶段执行，示例代码如下：

---
- name: 生产环境补丁更新全流程
  hosts: all
  gather_facts: true
  serial: 100% # 动态分组阶段全量运行
  pre_tasks:
    - name: 动态拆分DC为两个批次（自动取50%节点为第一批，保证任意时刻至少1台DC在线）
      group_by:
        key: "patch_dc_batch{{ 1 if ansible_play_hosts_all.index(inventory_hostname) < (ansible_play_hosts_all | length // 2) else 2 }}"
      when: "'dcs' in group_names"

    - name: 动态生成SQL依赖/非依赖web服务器分组
      group_by:
        key: "sql_web_{{ 'dependent' if sql_dependent is defined and sql_dependent else 'non_dependent' }}"
      when: "'webservers' in group_names"

# 阶段1：更新第一批DC，验证正常后再进入后续步骤
- name: 分批更新DC第一批
  hosts: patch_dc_batch1
  serial: 1 # 单台更新避免同时故障
  tasks:
    - include_tasks: common_patch_update.yml # 你的通用补丁更新逻辑
    - name: 验证DC服务正常
      wait_for:
        port: 53
        state: started
        delay: 30

# 阶段2：更新SQL服务器，验证完全恢复后再更新依赖的web
- name: 更新SQL服务器
  hosts: dbs
  serial: 1 # 可根据SQL高可用配置调整并行数
  tasks:
    - include_tasks: common_patch_update.yml
    - name: 验证SQL服务正常
      wait_for:
        port: 1433
        state: started
        delay: 60

# 阶段3：更新有SQL依赖的web服务器
- name: 更新SQL依赖的web服务器
  hosts: sql_web_dependent
  serial: 2 # 可根据业务容量调整并行数
  tasks:
    - name: 停业务服务避免脏数据
      service:
        name: "{{ item }}"
        state: stopped
      loop: "{{ web_services }}" # 你预定义的web服务列表
    - include_tasks: common_patch_update.yml
    - name: 验证与SQL连接正常
      wait_for:
        host: "{{ sql_host }}"
        port: 1433
        state: started
        timeout: 10
    - name: 恢复业务服务
      service:
        name: "{{ item }}"
        state: started
      loop: "{{ web_services }}"

# 阶段4：并行更新无依赖的主机（第二批DC + 无SQL依赖的web）
- name: 并行更新剩余无依赖主机
  hosts: patch_dc_batch2,sql_web_non_dependent
  serial: 5 # 可根据资源情况调整并行数
  tasks:
    - include_tasks: common_patch_update.yml
    - name: 验证对应服务正常
      wait_for:
        port: "{{ service_port }}"
        state: started
        delay: 30

方案优势 #

• 原有业务分组完全保留，日常批量对web、DC、DB下发配置不受任何影响
• 无需维护额外的静态补丁分组，DC分批逻辑自动适配DC数量变化，后续新增DC无需手动调整分组规则
• 仅需为少量有特殊依赖的主机标记属性，100台规模的集群运维成本几乎可以忽略
• 各阶段自带校验逻辑，完全满足生产环境的高可用、依赖约束要求

内容的提问来源于stack exchange，提问作者EdFred