Ansible混合环境自动化：Windows与Linux统一配置管理实战

前言：从 Windows 专属到异构统一的必然跨越

在前序系列中，我们深度耕耘了 Windows 生态内的自动化工具链。但现代企业的 IT 基础设施早已不是纯 Windows 世界：开发团队需要 Linux 容器宿主机、边缘计算节点运行 Ubuntu Core、数据库集群依赖 RHEL......若为每类系统维护独立的管理工具（DSC for Windows + Puppet for Linux + Shell Scripts for Legacy），不仅人力成本倍增，更会导致策略不一致、审计碎片化。

Ansible 的价值在于其无代理架构 与跨平台原生支持。它通过 SSH 管理 Linux，通过 WinRM 管理 Windows，用同一套 YAML 语法描述所有系统的期望状态。更重要的是，它能与前文所述的 Intune、DSC、Veeam 等工具无缝协同，成为串联整个运维体系的"通用胶水层"。

WinRM 安全加固：Windows 纳管的前提

Ansible 管理 Windows 依赖 WinRM，但其默认配置存在安全风险。生产环境必须执行以下加固：

1. 启用 HTTPS WinRM（禁用 HTTP）

复制代码

# 生成自签名证书（或使用企业 CA 签发）
$cert = New-SelfSignedCertificate -DnsName "ansible-winrm.corp.local" `
    -CertStoreLocation Cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(5)

# 创建 HTTPS 监听器
winrm create winrm/config/Listener?Address=*+Transport=HTTPS "@{Hostname=`"ansible-winrm.corp.local`"; CertificateThumbprint=`"$($cert.Thumbprint)`"}"

# 删除默认 HTTP 监听器
winrm delete winrm/config/Listener?Address=*+Transport=HTTP

# 防火墙仅开放 5986/TCP
New-NetFirewallRule -Name "WinRM-HTTPS" -DisplayName "WinRM over HTTPS" `
    -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow

2. 使用 Kerberos 认证（替代 Basic/CredSSP）

在 Ansible 控制端配置 group_vars/windows.yml：

复制代码

ansible_connection: winrm
ansible_winrm_transport: kerberos
ansible_winrm_kerberos_delegation: true
ansible_port: 5986
ansible_winrm_scheme: https
ansible_winrm_server_cert_validation: validate  # 企业CA证书设为validate，自签名设为ignore

安全红线 ：永远不要在生产环境使用 ansible_winrm_transport: basic。Basic 认证以 Base64 明文传输凭据，即使走 HTTPS 也存在内存转储泄露风险。Kerberos 或 NTLM 是唯一可接受选项。

跨平台 Playbook 设计：一套代码，双端执行

Ansible 的强大在于抽象差异。以下为同时配置 Windows 与 Linux NTP 客户端的示例：

复制代码

---
- name: Configure NTP across hybrid environment
  hosts: all
  tasks:
    - name: Set NTP server on Windows
      ansible.windows.win_regedit:
        path: HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
        name: NtpServer
        data: "time.corp.local,0x9"
        type: string
      when: ansible_os_family == "Windows_NT"
      notify: Restart W32Time

    - name: Set NTP server on Linux
      ansible.builtin.lineinfile:
        path: /etc/chrony.conf
        regexp: '^server time\.corp\.local'
        line: 'server time.corp.local iburst'
      when: ansible_os_family == "RedHat" or ansible_os_family == "Debian"
      notify: Restart chronyd

  handlers:
    - name: Restart W32Time
      ansible.windows.win_service:
        name: w32time
        state: restarted
      when: ansible_os_family == "Windows_NT"

    - name: Restart chronyd
      ansible.builtin.service:
        name: chronyd
        state: restarted
      when: ansible_os_family != "Windows_NT"

设计原则 ：优先使用 when: ansible_os_family 做条件分支，而非拆分为两个 playbook。这确保业务逻辑集中维护，避免策略漂移。对于复杂差异，封装为 Role 并在 tasks/main.yml 中按 OS 分发任务文件。

与现有体系的协同：Ansible 不是替代者

Ansible 应作为前文工具的补充层，而非替代品：

场景	推荐工具	Ansible 角色
Windows 终端初始部署	Autopilot / MDT	部署后首次配置（安装 Agent、加入域）
Windows 持续配置合规	DSC + Intune	定期漂移检测与修复（DSC 更适合声明式持续收敛）
Linux 服务器批量配置	Ansible	主力工具（DSC for Linux 生态薄弱）
跨平台应用部署	Ansible	统一编排（如同时在 Win/Linux 部署监控 Agent）
备份策略下发	Veeam + Ansible	Ansible 调用 Veeam PowerShell 模块批量配置备份作业
软件资产采集	Intune SAM	Ansible 补充采集 Intune 无法识别的绿色软件

关键洞察：DSC 擅长"持续保持状态"，Ansible 擅长"批量执行动作"。两者结合才是最优解：用 Ansible 完成一次性配置变更，用 DSC 确保后续不被篡改。

角色复用与 Galaxy 最佳实践

避免重复造轮子，善用 Ansible Galaxy 社区角色：

bash 复制代码

# 安装经过验证的 Windows 角色
ansible-galaxy install ansible.windows.win_updates
ansible-galaxy install chocolatey.chocolatey

# 在项目 requirements.yml 中声明依赖
collections:
  - name: ansible.windows
    version: ">=2.0.0"
  - name: chocolatey.chocolatey
    version: ">=1.0.0"
roles:
  - name: geerlingguy.ntp
    version: "2.3.1"

安全警告 ：Galaxy 角色需严格审查。仅使用 ansible.windows、chocolatey.chocolatey 等官方/认证集合；第三方角色必须阅读源码并检查是否有硬编码凭据或不安全操作。生产环境建议 fork 后内部托管。

常见排错：WinRM 连接与执行失败速查

错误信息	根因	解决方案
`Unauthorized`	Kerberos 票据过期或 SPN 未注册	执行 `kinit user@DOMAIN` 刷新票据；检查 `setspn -L hostname`
`SSL certificate verify failed`	证书不受信任或主机名不匹配	确认 `ansible_winrm_server_cert_validation` 设置；检查证书 SAN 字段
`The requested operation requires elevation`	UAC 阻止远程提权	在 WinRM 配置中启用 `AllowRemoteShellAccess=true`；或使用 `become: yes` + `become_method: runas`
`Module not found`	Collection 未安装或版本不兼容	执行 `ansible-galaxy collection list` 验证；确保 `requirements.yml` 版本约束正确
任务执行超时	WinRM 空闲超时或长命令阻塞	设置 `ansible_winrm_operation_timeout_sec: 600`；对长任务改用异步模式 `async: 3600`

调试技巧 ：在 playbook 中添加 -vvv 参数可查看完整 WinRM SOAP 报文；在 Windows 端启用 WinRM 分析日志：wevtutil sl Microsoft-Windows-WinRM/Analytic /e:true，排查服务端拒绝原因。

结语：异构统一是自动化体系的终极形态

从 Windows 单机修复到 Autopilot 云部署，从 DSC 配置到软件资产管理，从 WTG 特种方案到如今的 Ansible 跨平台纳管，我们终于构建了 "Windows 深度治理 + 异构统一编排" 的企业级运维体系。

Ansible 不是对前文工具的否定，而是将它们串联为有机整体的神经中枢。当您的自动化能力不再受限于单一操作系统，才能真正以业务视角而非技术栈视角定义基础设施。至此，终端与服务器的自动化管理方达成真正意义上的全域圆满。