使用 PowerShell DSC 和 Ansible 在 Windows 中实现高级自动化

信息技术数字 » 资源 » 使用 PowerShell DSC 和 Ansible 在 Windows 中实现高级自动化

如果您从事 Windows 基础架构相关工作，并且对PowerShell、DSC、Ansible 和自动化等术语耳熟能详，那么您可能已经知道，有效地结合使用这些技术可以彻底改变您管理服务器的方式。从在 Windows 向导中手动点击操作，到完全声明式且可重复的配置，这将使您摆脱疲于奔命的救火工作，拥有一个完全可控的环境。

本文将深入探讨如何 PowerShell 的期望状态配置 (DSC) 和 Ansible 完美契合 为了大规模管理 Windows（和 Linux），WinRM、Azure Automation、Terraform 或 cloud-init 等技术扮演着怎样的角色？如何借助该模块从 Ansible 利用现有的 DSC 资源？ win_dsc您将看到实际示例、真实用例以及决定何时使用原生 DSC、Ansible 模块或其他自动化方法的标准。

概述：使用 PowerShell、DSC 和 Ansible 实现 Windows 自动化

PowerShell 和 Ansible 的目标相同：以可复现的方式自动化系统的配置和管理。区别在于它们的方法。DSC 是集成到 PowerShell 中的配置管理平台，主要面向 Windows 系统（尽管它也可以通过 OMI 与 Linux 系统配合使用），而 Ansible 则是一个多用途、跨平台的自动化引擎，旨在从单一入口点协调混合异构基础架构。

借助Red Hat Ansible 自动化平台，您无需安装额外的代理即可实现 Windows 服务器的自动化，它利用WinRM 或 OpenSSH作为连接通道，并可利用 DSC 资源、Ansible 模块和 PowerShell 脚本。所有这些都通过YAML playbook进行组织，您可以在 playbook 中定义每个主机（包括 Windows 和 Linux 主机）应达到的状态。

另一方面，PowerShell 的所需状态配置提供了数百个专门的资源，用于配置几乎所有 Windows 组件：服务、系统功能、IIS、SQL Server、Active Directory、注册表、文件等。这些资源封装了检查和应用所需状态的逻辑，因此您只需声明“您希望机器处于什么状态”。

关键在于，通过 Ansible，您可以直接通过模块使用这些 DSC 资源。 ansible.windows.win_dsc将 Ansible 的编排能力与 DSC 提供的 Windows 特定配置深度相结合。这样您就可以实现 两全其美的 无需重复劳动。

WinRM 和对 Windows 的远程访问（用于 Ansible）

为了使 Ansible 能够管理 Windows 服务器，必须了解WinRM（Windows 远程管理）的工作原理。WinRM 是微软基于 HTTP/HTTPS 的内置远程管理技术，也是 Ansible 在 Windows 机器上执行任务的标准通道。

第一步是在目标主机和运行 Ansible 的控制节点上正确配置 WinRM。这涉及到调整身份验证、加密、权限，并且通常还需要处理非交互式登录等功能，即在没有活动用户会话的情况下发出命令。这种非交互式会话环境会使诸如Windows 更新或双向身份验证等任务变得复杂，因为在这些场景中，您需要访问第二个远程资源（例如，另一台服务器上的共享）。

使用 Red Hat Ansible 自动化平台的优势在于，它允许您集中、安全地编写凭据和身份验证机制，从而简化这些复杂情况的处理。此外，该平台还可以使用OpenSSH 访问 Windows Server，这在现代 Windows 版本中越来越普遍。

实际上，结合 WinRM、Ansible 的凭证管理和 DSC 功能，您可以构建强大的自动化流程，即使在安全限制较高的环境中也能无人值守地运行。

PowerShell DSC：声明式配置平台

PowerShell Desired State Configuration (DSC) 是一个集成到 Windows 中的声明式配置管理平台。借助 DSC，您可以通过代码定义计算机的配置方式：安装哪些角色和功能、激活哪些服务、设置哪些注册表参数、创建哪些文件或目录等等。

DSC配置描述了一组节点的期望状态。每台受管计算机都运行一个本地配置管理器 (LCM)，该管理器负责读取这些配置、检查实际状态并应用必要的更改。此外，您还可以设置一个拉取服务器，该服务器集中管理配置，节点通过该服务器更新配置并报告合规性。

DSC 不仅限于 Windows 系统：通过开放管理基础架构 ( OMI ) 服务器，它也可以与Linux 系统配合使用。然而，它真正的优势在于 Windows 环境，社区已经开发了大量专门的资源，用于配置 IIS、SQL Server 或 Active Directory等各种任务。

DSC 的一大优势在于它关注结果而非步骤。您只需声明状态（例如，“此功能必须存在，此服务必须已启动，此寄存器值必须已配置”），引擎便会负责实现该状态，并在出现任何偏差时进行检查和纠正。

Ansible 如何与 DSC 集成：win_dsc 模块和编排

理论上，你可以单独使用 DSC，但实际上，将其与Ansible 结合使用作为编排层会更加有效。Ansible 负责管理清单、有序执行任务、系统间协调以及与 CI/CD 流水线的集成，而 DSC 则提供操作 Windows 内部机制所需的特定资源。

模块 ansible.windows.win_dsc 它是连接两个世界的桥梁。该模块调用了一个 DSC资源类 在目标 Windows 主机上。在 playbook 中，您只需定义：

• 资源名称：您要使用的 DSC 资源的名称（例如， File, WindowsFeature, Service, Registry, xWebsite等）。
• 其余参数直接对应于 DSC资源的属性 （例如， DestinationPath, Ensure, Name, State等）。

当 Ansible 执行任务时，它会将这些参数转换为临时的 DSC 配置，将其应用到主机，并收集结果（包括是否发生了任何更改）。这样，您就可以重用整个 DSC 资源目录，而无需为每种情况编写特定的 Ansible 模块。

底层执行流程遵循一致的模式：Ansible 通过 WinRM 发送任务，Windows 系统根据参数生成 DSC 配置，DSC 引擎首先调用 Test-TargetResource 检查当前状态，如果检测到差异，则执行 Set-TargetResource 应用这些更改。Ansible 会收到一份报告，其中指示是否有任何内容被修改以及任何相关的调试消息。

当你们结合使用时，这种耦合作用尤其强大。 适用于 Windows 的 Ansible 原生模块 （如 win_file, win_service, win_regedit, win_psmodule等等）在 DSC 提供更精细的选择或更强大的功能覆盖范围的领域，可以使用 DSC 资源。

DSC 属性的类型以及如何在 Ansible 中映射它们

每个 DSC 资源都定义了一组属性。 明确定义的类型 （字符串、布尔值、数组、复杂的 PowerShell 类型等）。在使用 Ansible 时，您必须将这些属性转换为 YAML 语法 保持正确的类型。该模块 win_dsc 它能自动完成很多转换工作，但了解一些关键案例还是很有必要的。

对于像这样的简单类型 o 映射关系很简单：YAML 风格的带引号字符串和小写布尔值（true, false），避免写作 $true o $false 就像在 PowerShell 中一样。对于类型的属性 通常的做法是使用 ISO 8601格式 （例如， "2019-02-22T13:57:31Z"）并确保该值被序列化为字符串，方法是用引号将其括起来。

类型属性 它们是一种特例。由于这种类型无法直接序列化为 JSON，Ansible 使用了一种约定：定义两个参数，并用后缀分隔。 _username y _password （例如， Credential_username y Credential_password该模块会生成对象。 PSCredential 在远程主机上，基于这两个值。

对于类型 这些表示基于自定义资源类的字典；在 YAML 中，它们以键值映射的形式表示。您应该查看资源文档（通常在文件中）。 <nombre_recurso>.schema.mof）了解哪些键是允许的以及每个键的类型。实际上，它们被定义为： 嵌套字典 在模块内 win_dsc.

最后，类型属性 以及数组 (], ]等等）以字典或 YAML 列表的形式表示。对于数组，建议使用 正版 YAML 列表 而不是用逗号分隔值的字符串，因为这样可以避免手动解析，并降低出现细微错误的概率。

使用 Ansible 中的 DSC 的实际示例

一旦你掌握了模块的基本结构 win_dsc你可以结合各种资源来建造 非常全面的配置手册以下是一些适合使用DSC的常见场景：

• 文件和目录管理 利用资源 File创建文件夹结构，部署包含特定内容的配置文件，确保某些元素存在或已被删除。
• 安装 Windows 角色和功能 同 WindowsFeature：IIS、.NET Framework、Telnet客户端、管理工具等。
• 服务控制 利用资源 Service状态（已启动/已停止）、启动类型（自动、手动）、服务帐户等。
• 注册表设置 同 Registry安全值、等待时间、协议参数、系统加固。
• 高级 IIS 设置 使用以下模块 xWebAdministration 和资源 xWebsite, xWebAppPool等等。

在所有这些情况下，Ansible 只是简单地描述了 DSC 资源的参数，而 DSC引擎负责检查和应用 状态。此外，从 Ansible 2.8 开始，该模块 win_dsc 它会自动根据资源定义验证参数：如果您使用错误的属性名称、将必填字段留空或传递超出范围的值，任务将失败并显示明确的错误。

如果你运行 Ansible 时 冗长繁复（例如， -vvv)输出结果将包含详细信息 invocation.module_args 有关已使用的选项和可用的选项的信息，对于调试和发现可以在每个资源中配置哪些字段都非常有用。

另请注意，您可以使用该参数。 PsDscRunAsCredential 这样一来，DSC 资源就可以以不同于系统的用户身份运行。这对于访问注册注册表单元非常有用。 HKEY_CURRENT_USER Ansible 连接到的用户，或者在需要特定安全上下文的场景中。

自定义 DSC 资源和 PowerShell 库

Windows 集成的 DSC 资源可以满足许多需求，但真正的强大之处在于使用PowerShell Gallery 中发布的资源或第三方软件包。这些模块几乎涵盖了所有方面：Active Directory、SQL Server、高级 IIS、安全策略等等。

您可以使用 cmdlet 发现可用资源 Find-DscResource 或者直接浏览 PowerShell 库。一旦确定了您感兴趣的模块（例如， xWebAdministration o SqlServerDsc），您可以通过以下几种方式将其安装到主机上：

• 手动安装 Install-Module 从目标服务器上的 PowerShell 执行。
• 使用 Ansible 模块 win_psmodule 从 PowerShell Gallery 自动安装。
• 提前下载并手动抄写。 对于无法访问互联网的服务器，将模块保存在包含在以下目录中： PSModulePath （例如， C:\Program Files\WindowsPowerShell\Modules).

在网络连接不畅的环境中工作时，一种常见的策略是使用一台可以访问互联网的服务器。 保存模块 Save-Module 在本地路径中，然后将该目录复制到生产机器。之后，进行配置。 PSModulePath 也可以使用 Ansible 进行调整，例如使用以下模块： win_path这样 PowerShell 就可以在无需人工干预的情况下检测到这些资源。

安装完成后，该模块 win_dsc 可以调用这些包中的任何资源 只需说出名字即可 resource_name这为重用成熟的解决方案（例如 Active Directory DSC 模块）来执行诸如此类的任务打开了大门。 创建用户、组织单元、组或配置策略一切都由你的战术手册掌控。

此外，还有一个 PowerShell 模块，可以让你从 DSC 资源自动生成 Ansible 模块。其原理是检查 DSC 资源，逐一创建映射其参数的 Ansible 模块，然后像使用标准模块一样使用它。这些生成器可以从 PowerShell 库下载资源，并创建数十个模块，从而进一步扩展 Ansible 在 Windows 自动化生态系统中的应用。

除了 DSC 和 Ansible 之外：Azure 中的其他自动化工具

如果您的基础架构运行（或将要运行）在 Azure 上，那么值得关注一下其他可以与PowerShell DSC 和 Ansible互补的工具。关键不在于选择哪一个，而在于了解它们如何融入整个流程：基础架构创建、系统配置、应用程序部署和持续运维。

在“基础设施即代码”领域，Terraform或 Azure 原生语言（ARM 模板和 Bicep）等解决方案允许您使用声明式文件定义网络、虚拟机、存储和托管服务。Terraform 使用其自身的 HCL 语言，而 Bicep 则简化了旧版 ARM 模板的语法，但它们都能很好地集成到 CI/CD 流水线中，并且可以与 Ansible 结合使用，在虚拟机创建后对其进行配置。

阶段 Linux机器的初始配置Azure 支持 云初始化它会在首次启动时执行脚本并配置用户、软件包或配置文件。这些文件 #cloud-config通常采用 base64 编码，与发行版无关，并且依赖于每个发行版自己的软件包管理器，您无需担心。

在运维自动化领域，Azure Automation 扮演着重要的角色。它使用运行手册（通常是 PowerShell 或 Python 脚本），这些运行手册可以按需执行，也可以按计划执行，既可以在 Azure 资源上执行，也可以使用混合运行手册工作器在本地环境中执行。此外，它还提供托管的 DSC服务，允许您发布配置并监控一组机器的合规性。

最后，Azure DevOps、Jenkins、Chef、Puppet 和 Packer等 CI/CD 和应用生命周期管理工具完善了整个生态系统。它们各自负责一部分工作：从编译和测试代码到生成自定义机器镜像，再到通过自动化测试确保合规性。

Windows 更新、软件包和应用程序管理

对于任何系统团队来说，最关键的任务之一就是确保 Windows 系统及时更新补丁和补丁程序。微软提供 Windows 更新程序，并且在许多企业环境中还使用 Microsoft Configuration Manager (SCCM) 来管理部署。然而，当需要多次重启、维护窗口期紧张或需要复杂的编排方案时，这些机制可能会失效或变得不可靠。

Ansible 自动化平台能够控制更新的执行，与 Windows 更新集成，并自动管理必要的重启，从而使单个任务可以安装数十个或数百个补丁，同时保持对节点最终状态的控制。

在应用程序安装方面，Windows 缺乏像 Linux 发行版那样统一的原生软件包管理器。Microsoft Store 并非为自动化批量部署而设计：它缺乏成熟的命令行工具，并且严重依赖图形界面，这使得它在自动化流程中难以使用。

为了克服这一限制，Ansible 集成了多个模块，实现了Windows 系统中基本的软件包管理功能，尤其值得一提的是，它与Chocolatey 或Winget 等 Windows解决方案配合使用效果极佳，提供了类似于传统软件包管理器的幂等性。通过结合使用 Chocolatey、DSC 和 Ansible playbook，您可以轻松实现服务器或 VDI 软件目录的标准化，而无需进行太多人工干预。

如果再加上使用 DSC 资源来强制执行与这些应用程序相关的注册表配置、服务和策略，就可以在 Windows 环境中实现软件生命周期的全面自动化，从初始安装到强化配置和定期更新。

Windows Teams 的培训、最佳实践和应用

在许多纯粹基于 Windows 的 IT 团队中，管理工作仍然始于图形控制台和向导的点击操作。通常会有几十甚至几百台虚拟机运行在 VMware 或 Hyper-V 上，服务器创建过程都是手动完成的。向自动化的转变通常发生在团队成员厌倦了重复相同的任务，开始编写PowerShell 脚本的时候。

在这种情况下，一个合理的问题出现了：“我是继续单独使用 PowerShell，还是切换到 DSC，再配置 Ansible……或者干脆全部都做？” 最务实的答案通常是将它们结合起来：利用现有的 PowerShell 和 DSC 知识，同时引入 Ansible 作为编排层，以获得标准化能力以及与其他平台的集成能力。

针对 Windows 管理员，有一些专门的课程从 Ansible 的零基础开始，重点讲解以下内容：如何配置 Windows 系统以使用 Ansible 进行管理，如何编写有效的 playbook，如何集成Ansible Tower 或 AWX以从集中且安全的 Web 界面启动自动化，以及如何重用这些 playbook 中的 DSC 代码，以免浪费已经完成的工作。

在实践中，许多团队采用渐进式策略：首先自动化简单的任务（服务、角色、PowerShell 模块安装），然后利用 DSC 资源进行重复配置（IIS、AD、SQL、安全策略），并逐步将自动化集成到应用程序交付管道和重复性操作任务中。

定义样式指南、源代码控制以及剧本和 DSC 配置的测试也很重要，这样自动化才能真正成为“基础设施即代码”，而不仅仅是一些没有版本控制或修订的松散脚本。

通过整合PowerShell DSC、Ansible 模块、WinRM、Chocolatey 和 Azure 工具，我们构建了一个强大的生态系统，在这个系统中，机器创建、详细配置、应用程序部署和持续维护不再依赖于手动 RDP 会话。最终，我们获得了一个更加一致、可审计和可复现的环境，其中变更会自动记录在代码中，并大幅减少了人为错误。