使用 Ansible 管理 Windows 主机

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

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

引导 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 远程处理 - psrp

  • SSH - ssh

  • Windows 远程管理 - winrm

PSRP 和 WinRM

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

  • 可以稍微快一点

  • 当 Windows 节点处于负载状态时，不太容易出现超时问题

  • 更好地支持代理服务器

有关如何配置 WinRM 以及如何在 Ansible 中使用 psrp 和 winrm 连接插件的更多信息，请参见 Windows 远程管理。

SSH

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

注意

虽然自 Ansible 2.8 起，Ansible 就已支持将 SSH 连接插件与 Windows 节点一起使用，但官方支持仅在 2.18 版本中添加。

使用 SSH 而不是基于 WinRM 的传输的一些好处是

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

  • SSH 支持基于密钥的身份验证，这比证书更容易管理

  • SSH 文件传输比 WinRM 快

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

哪些模块可用？

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

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

此外，以下 Ansible Core 模块/操作插件可与 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 Linux 子系统（WSL）或在容器中在 Windows 上运行 Ansible。

注意

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

Windows facts

Ansible 以与其他 POSIX 主机类似的方式收集来自 Windows 的 facts，但有一些差异。为了向后兼容，某些 facts 可能采用不同的格式，或者根本不可用。

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

ansible windows -m setup

常见的 Windows 问题

命令在本地工作，但在 Ansible 下不工作

Ansible 通过网络登录执行命令，这可能会改变 Windows 授权操作的方式。这可能会导致在本地工作的命令在 Ansible 下失败。这些失败的一些示例是

  • 该进程无法将用户的凭据委派给网络资源，从而导致 拒绝访问 或 资源不可用 错误

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

  • 通过网络登录运行时，某些 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

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

另请参阅

Ad hoc 命令简介

基本命令示例

使用 Playbook

学习 Ansible 的配置管理语言

您应该开发模块吗？

如何编写模块

期望状态配置

将 Ansible 与 Windows Desired State Configuration 一起使用

Windows 性能

管理 Windows 主机的性能注意事项

使用 Ansible 和 Windows

Windows 使用指南

邮件列表

问题？帮助？想法？请访问 Google Groups 上的列表

实时聊天

如何加入 Ansible 聊天频道