使用 Ansible 管理 Windows 主机

管理 Windows 主机与管理 POSIX 主机有所不同。如果您有运行 Windows 的受管节点，请查看这些主题。

这是本指南涵盖的所有主题的索引。

引导 Windows (Bootstrapping Windows)

Windows 节点必须运行 Windows Server 2016 或 Windows 10 或更高版本。由于这些版本的 Windows 默认自带 PowerShell 5.1，因此引导 Windows 节点没有额外的要求。

对每个 Windows 版本的支持与其操作系统的扩展支持生命周期绑定，通常为自发布之日起 10 年。Ansible 针对 Windows 的服务器版本进行了测试，但仍应与 Windows 10 和 11 等桌面版本兼容。

连接到 Windows 节点

Ansible 默认使用 OpenSSH 连接到 POSIX 受管节点。Windows 节点也可以使用 SSH，但从历史上看，它们使用 WinRM 作为连接传输方式。可用于 Windows 节点的受支持连接插件有：

  • 基于 WinRM 的 PowerShell Remoting - psrp

  • SSH - ssh

  • Windows 远程管理 - winrm

PSRP 和 WinRM

历史上，Ansible 使用 Windows 远程管理 (WinRM) 作为管理 Windows 节点的连接协议。psrp 和 winrm 连接插件都运行在 WinRM 之上，且都可以作为 Windows 节点的连接插件。psrp 是一个较新的连接插件，相比 winrm 插件具有一些优势，例如：

  • 速度可能略快

  • 当 Windows 节点处于高负载时，较不容易出现超时问题

  • 对代理服务器更好的支持

有关 WinRM 如何配置以及如何在 Ansible 中使用 psrp 和 winrm 连接插件的更多信息，请参阅 Windows Remote Management。

SSH

SSH 是用于 POSIX 节点的传统连接插件，但它也可以用来管理 Windows 节点，替代传统的 psrp 或 winrm 连接插件。

注意

虽然 Ansible 自 2.8 版本起就支持在 Windows 节点上使用 SSH 连接插件，但官方支持是在 2.18 版本中才正式添加的。

使用 SSH 相比基于 WinRM 的传输方式的一些优势包括：

  • 在非域环境中，SSH 可能更容易配置

  • SSH 支持基于密钥的身份验证，比管理证书更简单

  • SSH 的文件传输速度比 WinRM 更快

有关如何为 Windows 节点配置 SSH 的更多信息，请参阅 Windows SSH。

有哪些可用模块？

大多数 Ansible 核心模块是为类 Unix 机器和其他通用服务组合编写的。由于这些模块是用 Python 编写的，并且使用了 Windows 上不存在的 API，因此它们无法在 Windows 上运行。

有一些专门的 Windows 模块是用 PowerShell 编写的，旨在运行在 Windows 主机上。这些模块的列表可以在 Ansible.Windows, Community.Windows, Microsoft.Ad, Chocolatey.Chocolatey 以及其他集合中找到。

此外，以下 Ansible Core 模块/操作插件 (action-plugins) 适用于 Windows：

  • add_host

  • assert

  • async_status

  • debug

  • fail

  • fetch

  • group_by

  • include

  • include_role

  • include_vars

  • meta

  • pause

  • raw

  • script

  • set_fact

  • set_stats

  • setup

  • slurp

  • template (同时也提供: win_template)

  • wait_for_connection

使用 Windows 作为控制节点

由于平台 API 的限制，Ansible 不能直接在 Windows 上作为控制节点运行。不过，您可以使用 Windows Subsystem for Linux (WSL) 或在容器中在 Windows 上运行 Ansible。

注意

Ansible 不支持 Windows Subsystem for Linux，且不应将其用于生产系统。

Windows 事实 (facts)

Ansible 收集 Windows 事实的方式与其他 POSIX 主机类似，但存在一些差异。为了向后兼容，某些事实的格式可能不同，或者可能根本无法获取。

要查看 Ansible 从 Windows 主机收集的事实，请运行 setup 模块。

ansible windows -m setup

常见的 Windows 问题

命令在本地可行但在 Ansible 下不可行

Ansible 通过网络登录执行命令，这可能会改变 Windows 授权操作的方式。这会导致在本地运行成功的命令在 Ansible 下失败。此类失败的一些示例包括：

  • 进程无法将用户的凭据委派给网络资源，导致出现 Access is  Denied（拒绝访问）或 Resource Unavailable（资源不可用）错误

  • 需要交互式会话的应用程序将无法工作

  • 某些 Windows API 在通过网络登录运行时受限

  • 某些任务需要访问 DPAPI 机密存储，而这在网络登录时通常不可用

常用的解决方法是使用 理解权限提升：become 来使用显式凭据运行命令。在 Windows 上使用 become 会将网络登录更改为交互式登录，并且如果为 become 身份提供了显式凭据，该命令将能够访问网络资源并解锁 DPAPI 存储。

另一种选择是在连接插件中使用允许凭据委派的身份验证选项。对于 SSH，可以通过显式的用户名和密码，或者通过启用委派的 Kerberos/GSSAPI 登录来实现。对于基于 WinRM 的连接，可以使用 CredSSP 或带有委派的 Kerberos。有关更多信息，请参阅特定连接的文档。

凭据被拒绝

连接到 Windows 主机时凭据被拒绝可能有几个原因。一些常见原因包括：

  • 用户名或密码错误

  • 用户帐户被锁定、禁用或不允许登录到该服务器

  • 用户帐户不允许通过网络登录

  • 用户帐户不是本地管理员 (Administrators) 组的成员

  • 用户帐户是本地用户，且未设置 LocalAccountTokenFilterPolicy

要验证凭据是否正确或用户是否允许登录主机，您可以在 Windows 主机上运行以下 PowerShell 命令以查看最近一次失败的登录尝试。这将输出事件详情，包括指示登录失败原因的 Status 和 Sub Status 错误代码。

Get-WinEvent -FilterHashtable @{LogName = 'Security'; Id = 4625} |
    Select-Object -First 1 -ExpandProperty Message

虽然并非所有连接插件都要求连接用户必须是本地管理员组的成员，但这通常是默认配置。如果用户不是本地管理员组的成员，或者是一个未设置 LocalAccountTokenFilterPolicy 的本地用户，身份验证将失败。

另请参阅

即席命令（ad hoc commands）介绍

基本命令示例

使用 Playbook

学习 Ansible 的配置管理语言

您应该开发模块吗？

如何编写模块

Windows 应用程序控制

在受 Windows App Control 管理的主机上使用 Ansible

Desired State Configuration (所需状态配置)

在 Windows 期望状态配置 (Desired State Configuration) 中使用 Ansible

Windows 性能

管理 Windows 主机的性能考虑

使用 Ansible 和 Windows

Windows 使用指南

邮件列表

有疑问？需要帮助？有想法？请访问 Google Groups 上的列表

实时聊天

如何加入 Ansible 聊天频道