PowerShell 2.0 CTP: remoting и один скрипт на сотню машин
Microsoft выпустила CTP PowerShell 2.0 с поддержкой WS-Management. Тестируем remoting и переписываем несколько bat-скриптов - результат неожиданно убедительный.
Microsoft выпускает PowerShell 2.0 CTP с поддержкой remoting на базе WS-Management/WinRM
На прошлой неделе Microsoft выкатила Community Technology Preview PowerShell 2.0. Главная фича - remoting: скрипт запускается локально, а выполняется на удалённых машинах через WS-Management (WinRM). Звучит как «ну и что, ssh давно умеет». Но если у вас десятки Windows-серверов и вы привыкли управлять ими через bat-скрипты, psexec и RDP-сессии - это немного другая история.
Мы взяли CTP и потратили пару дней, чтобы понять, стоит ли начинать перетаскивать туда реальные задачи.
Что такое WinRM и почему раньше не было
Windows Remote Management - это реализация WS-Management от Microsoft, протокол поверх HTTP/HTTPS. В Windows Vista и Server 2008 он уже есть из коробки, на Server 2003 и XP ставится отдельным пакетом. PowerShell 1.0, который появился в 2006-м, remoting не умел - скрипты можно было гонять только локально или через хаки вроде psexec. Вторая версия это исправляет, и CTP - первый публичный вкус того, как оно будет работать.
Настройка WinRM на целевых машинах простая: winrm quickconfig - и сервис поднят, правило в файерволе добавлено. На Server 2003 дополнительно ставим пакет WinRM 1.1. Звучит не страшно, пока не вспоминаешь, что машин таких у клиентов бывает по несколько десятков, и каждую надо разово подготовить. Сделали через групповую политику - скрипт запуска, который выполняет quickconfig и выходит с нулём. Не элегантно, но работает.
Как выглядит remoting в CTP
Базовая конструкция - Invoke-Command:
Invoke-Command -ComputerName server01, server02, server03 -ScriptBlock {
Get-Service -Name "wuauserv" | Select-Object Name, Status
}
Это запускает блок на трёх машинах параллельно и возвращает результаты обратно как объекты PowerShell. Не текст, не строки - объекты. Можно дальше их фильтровать, сортировать, передавать в другие командлеты.
Для сессий, которые нужно держать открытыми (и не платить за установку соединения при каждом вызове), есть New-PSSession и Enter-PSSession. Второй - интерактивный, фактически консоль прямо на удалённой машине без RDP. Первый - для пакетных задач, когда нужно сделать несколько операций в рамках одного соединения.
Что мы переписали
У нас на нескольких объектах живут bat-скрипты, которые через psexec делают разные рутинные вещи: проверяют статус служб, чистят временные директории, смотрят место на дисках. Bat + psexec - это последовательно, по одной машине, с разбором текстового вывода, который psexec иногда форматирует неожиданным образом.
Взяли три скрипта и переписали на PowerShell с remoting.
Проверка места на дисках. Было: bat запускает psexec \\server dir c:\ /-c, парсит вывод grep-ом через findstr. Стало - один Invoke-Command на список серверов, GetDiskFreeSpace через WMI, результат приходит числом в байтах. Никакого парсинга текста, сразу сравниваем с порогом, формируем список проблемных машин. Код раза в три короче, читается без словаря.
Статус служб. Похожая история. Раньше - цикл по серверам, psexec, sc query servicename, findstr "RUNNING". Теперь - Invoke-Command, Get-Service, фильтр по Status. Работает заметно быстрее - параллельность реальная, несколько машин отвечают одновременно.
Перезапуск зависших служб. Здесь интересней. Старый bat делал psexec с net stop и net start, и мы иногда теряли вывод или получали ложный ноль возврата. В PowerShell - Restart-Service внутри Invoke-Command, и если служба не поднялась, получаем исключение, которое можно поймать через try/catch и записать в лог. Нормальная обработка ошибок вместо анализа exit-кодов.
Что не понравилось
CTP есть CTP. Несколько раз Invoke-Command завис без объяснений на конкретных машинах - пришлось убивать сессию и разбираться. На Server 2003 с WinRM 1.1 были проблемы с аутентификацией Kerberos в некоторых конфигурациях домена - решали через NTLM явно в параметрах, но это костыль. Документация скудная, примеров мало, TechNet-статьи про 2.0 пишутся на ходу.
Ещё один момент - безопасность. WinRM открывает порт 5985 на всех серверах. Это новая поверхность атаки, которую надо закрыть на уровне файервола или ограничить списком разрешённых хостов. Групповая политика позволяет настроить доверенные хосты, так что ничего фатального, но требует осознанного подхода, а не quickconfig-и-забыл.
Итог по первым дням
Remoting в PowerShell 2.0 - это не просто «ещё одна фича». Это смена парадигмы управления Windows-инфраструктурой: вместо «подключился к каждой машине и сделал» получаешь «описал что сделать, скормил список машин, получил результаты». Параллельность, объекты вместо текста, нормальные исключения - всё это в bat со скриптами psexec не воспроизводится.
Понятно, что CTP - это не то, что стоит катить в продакшн на клиентские инфраструктуры прямо сейчас. Зависания, неполная документация, потенциальные сюрпризы со стабильностью. Но направление понятное, и в managed-сопровождении это выглядит как инструмент, который серьёзно упростит рутину при выходе нормального релиза.
Пока гоняем CTP на тестовом стенде и продолжаем переписывать скрипты - смотрим, где всплывут подводные камни.