Windows PowerShell: Совместное использование сценариев? Это просто!
Дон Джонс
Одним из многих недостатков первой версии PowerShell была сложность совместного использования сценариев. Конечно, легко скопировать файл сценария a .ps1 на другой компьютер или даже сжать его и отправить по электронной почте коллеге, но вот уже более десяти лет мы и так умеем это делать со сценариями VBScript. Если сценарий содержал повторно используемые функции, приходилось разбираться, как запускать его в своей среде, так что в результате частенько приходилось вносить изменения, чтобы заставить сценарий работать.
В целом, не идеально, но терпимо. Существенно сложнее было со сценариями, содержащими нестандартные виды формата или расширения типов, потому что такие дополнительные файлы надо было вручную загружать в оболочку, чтобы можно было воспользоваться сценарием.
Благодаря появлению модулей в Windows PowerShell v2 удалось добиться почти идеальной ситуации.
Самостоятельные модули PowerShell
Модуль — это просто набор взаимозависимых файлов. По типу содержимого модули можно грубо разделить на две категории: бинарный код и сценарии.
Бинарный модуль состоит из одного или более DLL-файлов, написанных на одном из языков Microsoft .NET Framework, например C# или Visual Basic. В версии v1 это называлось оснасткой PowerShell (PSSnapin), причем процесс его написания в Visual Studio практически не поменялся. При этом надо было написать установщик, регистрирующий DLL в оболочке. С модулями никакой установки не требуется. Вместо этого, модуль дополняется файлом с расширением .psd1, представляющим собой файл манифеста. Манифест — это просто XML-код, указывающий, какую DLL надо загрузить. Декларация может также указывать сопутствующие файлы расширения типов (.ps1xml) или файлы представления (.format.ps1xml).
Вот, как это работает: модуль должен устанавливаться в подкаталоге каталога \modules в Windows PowerShel. По умолчанию это каталог c:\windows\system32\windowspowershell\v1.0\modules. Поэтому, к примеру, модуль по имени MyModule попадет в папку c:\\windows\\system32\\windowspowershell\\v1.0\\modules\\mymodule, а файл манифеста получит имя mymodule.psd1. Все относящиеся к модулю файлы обычно попадают в ту же папку, что делает это решение практически самодостаточным.
Чтобы загрузить модуль, надо просто выполнить команду Import-Module MyModule. Оболочка попытается найти нужный модуль в папке по умолчанию modules (можно задать полный путь к импортируемому модулю, если он расположен в другом месте), находит PSD1-файл, считывает его и загружает указанные в нем файлы. Распространять модуль также просто: достаточно заархивировать все файлы и скопировать получившийся zip-файл на другой компьютер — никакой установки не требуется.
Развертывание модулей
Так где же обещанное упрощение распространения сценариев? Оно возможно со вторым типом модуля — модулем со сценарием. Это обычный сценарий Windows PowerShell с расширением файла .psm1, а не обычным .ps1. Размещение mymodule.psm1 в папке modules позволяет запускать сценарий командой Import-Module MyModule.
Обычно модуль со сценарием состоит полностью из функций, то есть при импорте модуля ничего, собственно, не выполняется — просто функции модуля загружаются в оболочку и становятся доступными в этой оболочке. Допустим, у нас есть такой модуль со сценарием:
Function Get-Inventory {
# (some code goes here)
}
Function Test-Connectivity {
# (some code goes here)
}
Function Write-Inventory {
# (some code goes here)
}
После импорта этого модуля в оболочке станут доступны функции Get-Inventory, Test-Connectivity и Write-Inventory — очень похоже на командлеты (кстати, в следующем месяце я покажу, как создать функцию, которая ведет себя почти как настоящий командлет). Функции могут даже содержать справку на основе комментариев (об этом я рассказывал в предыдущем выпуске своей колонки), что позволит каждому, кто импортировал модуль, выполнить команду Help Get-Inventory и увидеть инструкции по использованию этих функций.
Иногда хочется немного посекретничать
Иногда приходится создавать сложные модули со сценарием, содержащие функции, которые предназначены только для использования другими функциями, а не пользователем. Например, функции Test-Connectivity и Write-Inventory можно было бы сделать «закрытыми», то есть их должна вызывать функция Get-Inventory, а не пользователь.
По умолчанию команда Import-Module импортирует все, что есть в модуле, при этом все функции становятся видимыми пользователю оболочки. Это поведение можно изменить, просто задав список функций, которые должны быть видимыми — все остальные будут скрыты от пользователя оболочки. Для этого надо просто после создания своего модуля выполнить команду Export-ModuleMember:
Export-ModuleMember –function Get-Inventory
Можно также при необходимости экспортировать определенные в сценарии командлеты, переменные и псевдонимы. Чтобы узнать побольше, выполните команду Help Export-ModuleMember или откройте веб-страницу Export-ModuleMember.
Недостатки модулей
По моему мнению, у модулей PowerShell v2 только один недостаток:оболочка поддерживает только одну папку по умолчанию для их размещения и она находится в системной папке Windows, а хочется определенной гибкости. Но, посмотрев на содержимое переменной окружения PSModulePath, я обнаружил, что оболочка ищет сценарии еще и в папке Документы (Documents), а точнее в подпапке WindowsPowerShell\\Modules, и с той поры я размещаю свои сценарии именно там.
В будущем командлеты можно будет разрабатывать так, чтобы они загружали дополнительные модули из хранилищ в Интернете, что мало чем отличается от имеющейся в Unix функциональности Pear. Такие командлеты, скорее всего, будут загружаться в папку Документы или другую несистемную папку, а способность оболочки по умолчанию искать их в папке Документы была бы очень кстати.
Модули повсюду
Так как модули не нуждаются в установке, чтобы их «увидела» оболочка, они становятся все популярнее. По сути почти все расширения PowerShell в Windows Server 2008 R2 созданы как модули; единственное исключение — оснастка PowerShell автоматизации создания резервных копий сервера Windows (чтобы узнать, установлена ли эта оснастка, выполните команду Get-PSSnapin –registered). К тому же все больше кода, создаваемого сторонними разработчиками поставляется в виде модулей, в том числе командлеты, которые обращаются к хранилище кода в сообществе PoshCode.org.
Фактически, если вы опытный пользователь PowerShell, интересующийся написанием собственных командлетов, но не желающий разбираться в программировании в .NET Framework средствами Visual Studio, сочетание расширенных функций (о которых я расскажу в следующем месяце) и модулей позволит вам создавать собственные оснастки только как сценарии. Достаточно упаковать свои расширенные функции, которые выглядят и ведут себя как командлеты, и вы получите простую в распространении библиотеку повторно используемого кода.
Windows PowerShell v2 теперь доступен всем
Ранее Windows PowerShell v2 поставлялся только в составе Windows Server 2008 R2 и Windows 7, теперь эта оболочка и сопутствующие компоненты инфраструктуры управления доступны для Windows XP, Windows Server 2003, Windows Vista и Windows Server 2008. На странице support.microsoft.com/kb/968929 вы найдете ссылки для загрузки Windows PowerShell v2 для нужной вам ОС. В большинстве случаев новая оболочка будет поддерживать сценарии, созданные в версии 1; в своих последующих выпусках своей колонки, а буду предполагать, что вы используете 2.0.
Дон Джонс (Don Jones)* основатель компании Concentrated Technology. Дон регулярно отвечает на посвященные Windows PowerShell вопросы посетителей своего сайта ConcentratedTech.com. Он также пишет для Nexus.Realtimepublishers.com, поэтому многие из книг Дона доступны в бесплатной электронной форме.*
Материалы по теме
· Windows PowerShell: PowerShell и Active Directory