使用 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 核心模块/操作插件适用于 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 (also: win_template)

  • wait_for_connection

使用 Windows 作为控制节点

由于平台上的 API 限制,Ansible 无法在 Windows 上作为控制节点运行。但是,您可以使用 Windows 子系统 for Linux (WSL) 或在容器中在 Windows 上运行 Ansible。

注意

Windows 子系统 for Linux 不受 Ansible 支持,不应用于生产系统。

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 主机时,凭据被拒绝的原因有很多。一些常见原因是

  • 用户名或密码不正确

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

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

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

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

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

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

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

另请参见

自发命令简介

基本命令示例

使用剧本

学习 Ansible 的配置管理语言

您是否应该开发一个模块?

如何编写模块

期望状态配置

将 Ansible 与 Windows 期望状态配置一起使用

Windows 性能

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

使用 Ansible 和 Windows

Windows 使用指南

邮件列表

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

实时聊天

如何加入 Ansible 聊天频道