Ansible для Windows через WinRM: первые шаги без агента

В конце января мы рефакторили playbook-и на роли и жили в Linux-мире, где всё более-менее понятно. Но у нескольких клиентов на сопровождении инфраструктура смешанная: Linux для бэкенда, Windows Server для Active Directory, терминалов, IIS. И каждый раз, когда надо было что-то поправить на Windows - открывалась RDP-сессия, мышь, следующие полчаса ручного труда.

Ansible 1.7 добавил экспериментальную поддержку Windows через WinRM. «Экспериментальную» - это в их собственной документации, не наша оценка. Мы решили проверить, насколько это применимо в реальной жизни.

Что такое WinRM и почему это вообще работает

WinRM - Windows Remote Management, встроенный в Windows протокол удалённого управления на базе WS-Management. Ansible подключается к нему вместо SSH, используя Python-библиотеку pywinrm на стороне управляющей машины. На самом Windows-хосте ничего ставить не нужно - только настроить WinRM-листенер и открыть порт (по умолчанию 5985 для HTTP, 5986 для HTTPS).

Настройка WinRM на сервере делается одной командой в PowerShell:

winrm quickconfig

Но это только базовый вариант. Для production нужно разобраться с аутентификацией - Basic auth по HTTP в открытом виде нас не устраивает. Настраивали CredSSP: требует включить на сервере и указать в инвентаре ansible_winrm_transport: credssp. Провозились часа полтора, потому что CredSSP надо отдельно включать через Group Policy или PowerShell, и по умолчанию он выключен.

Инвентарь и переменные

Структура инвентаря для Windows-хостов выглядит так:

[windows_servers]
win-iis-01 ansible_host=192.168.10.50
win-iis-02 ansible_host=192.168.10.51

[windows_servers:vars]
ansible_user=administrator
ansible_password={{ vault_win_admin_pass }}
ansible_connection=winrm
ansible_winrm_transport=credssp
ansible_port=5985

Пароль - через ansible-vault, как мы делаем для Linux. Это нормально работает.

Первый ansible -m win_ping -i inventory windows_servers - и хосты ответили. Маленькое, но реальное удовольствие.

Что удалось автоматизировать

Писали роль под IIS. Задачи были конкретные: включить роль IIS, добавить компоненты (ASP.NET, Basic Auth), положить конфиг веб-сайта.

Несколько наблюдений из процесса:

• Модуль win_feature работает как ожидаешь - устанавливает Windows Features через DISM/PowerShell под капотом. win_feature: name=Web-Server state=present включает IIS. Идемпотентно - повторный запуск не ломает ничего.
• Модуль win_firewall_rule - самый приятный сюрприз. Добавлять правила файрвола через него проще, чем вручную в netsh или через GUI. Задача на разрешение порта 80 занимает три строки.
• Модуль win_copy для копирования файлов работает, хотя с путями надо быть аккуратным - обратные слеши в Windows-путях надо экранировать или использовать прямые, Ansible их принимает.
• Модуль win_regedit - для тех задач, где всё равно нужен реестр. Пригодился для настройки параметров IIS, которые через win_feature не достать.

Сама роль получилась компактной. Три таска вместо двадцати кликов в Server Manager.

Где спотыкаемся

Честно: поддержка Windows заметно беднее Linux. Список модулей с win_ префиксом небольшой - win_service, win_user, win_group, win_file, win_copy, win_template, win_command, win_shell. Для многих типовых задач нет готового модуля, и приходится использовать win_shell с PowerShell-командой. Это работает, но теряется идемпотентность - win_shell не знает, выполнялась ли задача раньше, и делает это снова.

Пример: настроить binding в IIS для конкретного сайта нет готового модуля. Пишешь win_shell с PowerShell через Import-Module WebAdministration. Это уже не декларативный подход, а скрипт в оболочке ansible.

Ещё одна проблема - win_template с Jinja2 иногда ведёт себя неожиданно с переносами строк. Windows использует CRLF, Jinja2 генерирует LF. В конфигах IIS это иногда не важно, иногда критично - зависит от того, какой парсер их читает.

Тестирования через --check (dry run) для Windows-модулей практически нет - большинство win_* модулей возвращают «skipped» в check mode, не показывая что реально изменится.

Итог на сейчас

Базовая автоматизация Windows работает. Мы уже применяем роль IIS на нескольких хостах клиентов, и это заметно - инженер не открывает RDP для типовых задач вроде «добавить правило файрвола» или «поставить компонент». Playbook запускается с управляющей Linux-машины, результат предсказуем.

Но называть это полноценной заменой ручного управления Windows-серверами пока рано. Для нестандартных задач всё равно нужен PowerShell в win_shell, а значит - думать про идемпотентность самостоятельно. Экосистема модулей намного меньше, чем для Linux.

Следующий шаг - посмотреть, что можно сделать с Active Directory. Модулей под AD в текущей версии нет совсем, но через win_shell и PowerShell AD-командлеты теоретически управляемо. Теоретически.