Ansible на Windows: первый опыт с win_feature, win_service и WinRM

Когда в Ansible 1.7 появились Windows-модули, мы отнеслись к этому скептически. Linux-инфраструктура у нас давно под Ansible, всё работает, roles разложены по полочкам. Но часть клиентов на сопровождении сидит на Windows Server 2012 R2 - и там по-прежнему ручная настройка, скрипты PowerShell в разрозненных файлах и привет через RDP. Иметь один инструмент для смешанного окружения - идея заманчивая. Решили попробовать.

Что нужно сделать до того как запускать playbook

Первый сюрприз - Ansible на Windows работает не через SSH, а через WinRM (Windows Remote Management). Это встроенный в Windows протокол управления, но по умолчанию он настроен так, что использовать его для автоматизации нельзя без дополнительных телодвижений.

На целевой Windows-машине нужно:

• Включить WinRM: winrm quickconfig
• Настроить аутентификацию CredSSP, которую Ansible использует для передачи учётных данных
• Создать самоподписанный сертификат или подключить нормальный, если WinRM слушает по HTTPS
• Разрешить CredSSP через групповую политику или Enable-WSManCredSSP

На контрольной машине (Linux) нужен Python-пакет pywinrm. Он не входит в стандартную установку Ansible.

Инвентарный файл для Windows-хоста выглядит иначе, чем привычный:

[windows]
win2012r2.example.com

[windows:vars]
ansible_connection=winrm
ansible_user=Administrator
ansible_password={{ vault_win_password }}
ansible_winrm_transport=credssp
ansible_winrm_server_cert_validation=ignore

cert_validation=ignore - да, некрасиво. Для тестового стенда сойдёт, в боевой среде нужно разбираться с сертификатами нормально.

Что реально работает

После настройки WinRM попробовали три модуля.

win_feature - управление ролями и компонентами Windows. Аналог Add-WindowsFeature / Install-WindowsFeature. Пример установки IIS:

- name: Установить IIS
  win_feature:
    name: Web-Server
    state: present
    include_sub_features: yes
    include_management_tools: yes

Запустили - отработало. Идемпотентность есть: повторный запуск показывает changed: false, ничего лишнего не делает. Это главное, чего ждёшь от Ansible.

win_service - управление Windows-службами. Остановить, запустить, изменить тип запуска:

- name: Отключить Telnet
  win_service:
    name: TlntSvr
    state: stopped
    start_mode: disabled

Работает. Привычный синтаксис, понятный результат.

win_copy - копирование файлов на Windows-хост. Скопировали конфигурационный файл в C:\inetpub\conf\ - сработало. Пути с обратными слешами можно писать как с обратными, так и с прямыми - Ansible разбирается сам.

Где трёт

CredSSP требует отдельного объяснения. Это протокол делегирования учётных данных: управляющий хост передаёт на целевую машину токен, который позволяет действовать от имени пользователя, включая доступ к сетевым ресурсам. Это нужно, например, чтобы playbook мог забрать файл с сетевой шары во время выполнения задачи.

Проблема в том, что включение CredSSP - отдельная настройка как на целевой машине, так и на клиентской стороне. По умолчанию отключено везде. Плюс в доменной среде это нужно согласовывать с политиками - CredSSP потенциально расширяет поверхность атаки, безопасники смотрят на него с прищуром.

Ещё одно: скорость. WinRM медленнее SSH. Playbook на 15 задач, который на Linux выполняется за несколько секунд, на Windows занимает заметно дольше - каждый вызов модуля идёт через PowerShell-сессию, это стоит времени. На большом количестве машин разница будет ощутимой.

Набор модулей скромный. win_feature, win_service, win_copy, win_command, win_shell - это почти весь список на сегодня. Нет win_user, нет нормальной работы с реестром, нет управления IIS-сайтами через отдельный модуль. Сложная настройка всё равно требует win_shell с PowerShell-скриптом внутри, что уже не сильно отличается от просто скрипта.

Что это даёт на практике

Смешанное окружение Linux + Windows в одном Ansible-репозитории - это реально работает. Playbook верхнего уровня распределяет задачи:

- hosts: linux_servers
  roles:
    - common
    - monitoring-agent

- hosts: windows_servers
  roles:
    - win_common
    - win_monitoring

Единая точка входа, единый инвентарь, единое хранилище секретов через Vault. Разница в реализации ролей - внутри win_common задачи на win_* модулях вместо привычных package/service, но логика та же самая.

Для базовых вещей - установить роль Windows, включить/выключить службу, скопировать файл - этого достаточно. Для всего остального пока win_shell с PowerShell.

Итог

Экспериментальная пометка в документации - честная. Поддержка Windows в Ansible 1.7 работает, но требует нетривиальной настройки WinRM и CredSSP, имеет узкий набор модулей и медленнее Linux-варианта. Это не инструмент для сложной настройки Windows-систем - это инструмент для базовой автоматизации и объединения смешанной инфраструктуры под одним управлением.

Для нас это ценно уже сейчас: один инвентарь, одно хранилище переменных и secrets, один pipeline деплоя для Linux и Windows. Ради этого стоило разобраться с WinRM.