使用 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 节点。psrpwinrm 连接插件都通过 WinRM 运行,可用作 Windows 节点的连接插件。psrp 连接插件是一个较新的连接插件,与 winrm 连接插件相比,它提供了一些好处,例如

  • 可能稍微快一点

  • 当 Windows 节点负载过重时,不太容易出现超时问题

  • 更好地支持代理服务器

有关如何配置 WinRM 以及如何在 Ansible 中使用 psrpwinrm 连接插件的更多信息,请参阅 Windows 远程管理

SSH

SSH 是传统上与 POSIX 节点一起使用的连接插件,但它也可以用于管理 Windows 节点,而不是传统的 psrpwinrm 连接插件。

注意

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

与基于 WinRM 的传输相比,使用 SSH 的一些好处是

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

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

  • SSH 文件传输比 WinRM 快

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

哪些模块可用?

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

有一些专门的 Windows 模块是用 PowerShell 编写的,旨在在 Windows 主机上运行。这些模块的列表可以在 Ansible.WindowsCommunity.WindowsMicrosoft.AdChocolatey.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 事实

Ansible 以与其他 POSIX 主机类似的方式从 Windows 收集事实,但有一些区别。出于向后兼容性的原因,某些事实可能采用不同的格式,或者根本不可用。

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

ansible windows -m setup

常见的 Windows 问题

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

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

  • 该进程无法将用户的凭据委托给网络资源,从而导致 Access is  DeniedResource Unavailable 错误

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

  • 通过网络登录时,某些 Windows API 会受到限制

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

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

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

凭据被拒绝

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

  • 用户名或密码不正确

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

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

  • 用户帐户不是本地 Administrators 组的成员

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

要验证凭据是否正确或用户是否允许登录主机,您可以在 Windows 主机上运行以下 PowerShell 命令以查看上次失败的登录尝试。这将输出事件详细信息,包括StatusSub 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 聊天频道