Windows PowerShell: модули
Операционная система: «Windows 10 Pro».
Программа «Windows PowerShell», версия 5.1.
Для каждого модуля программы «Windows PowerShell» в операционной системе «Windows» создается своя отдельная папка (каталог). В широком смысле модуль представляет собой набор файлов, который хранится в этой папке. В этот набор могут входить текстовые файлы с разнообразной вспомогательной информацией (помощь, файл readme, примеры применения, текст лицензии и так далее), текстовые файлы со скриптами (сценариями), которые имеют расширения «.ps1» и «.psm1», текстовый файл манифеста модуля с расширением «.psd1», бинарные файлы с расширением «.dll», другие файлы и подпапки с файлами. В узком смысле при программировании на скриптовом языке программы «Windows PowerShell» модулем называют скрипт, хранящийся в текстовом файле с расширением «.psm1».
Папки модулей для программы «Windows PowerShell» могут храниться где угодно на компьютере. Но программа «Windows PowerShell» самостоятельно может найти только те папки модулей, которые хранятся в местах, указанных в переменной $Env:PSModulePath . Получить значение любой переменной в программе «Windows PowerShell» можно, просто введя имя этой переменной в качестве команды в командной строке. Например:
$Env:PSModulePath
В ответ на эту команду программа «Windows PowerShell» возвратит значение этой переменной, которая в данном случае является строкой. В этой строке через точку с запятой перечислены пути к местам, в которых программа «Windows PowerShell» по умолчанию ищет папки модулей.
Чтобы просматривать эту строку было удобнее, можно с помощью специального оператора разделить строку на части (ориентируясь на разделитель «;») и вывести эти части в столбик. Например, с помощью следующей команды:
$Env:PSModulePath -split ";"
По умолчанию в этой переменной хранятся три пути. Но пути в эту переменную можно добавлять. У меня по умолчанию в этой переменной хранятся следующие значения:
C:\Users\Илья\Documents\WindowsPowerShell\Modules C:\Program Files\WindowsPowerShell\Modules C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
На другом компьютере начало этих путей может, конечно, отличаться. Предполагается, что по первому пути будут располагаться модули, которые доступны из аккаунта текущего пользователя операционной системы. По второму пути должны располагаться модули, доступные всем аккаунтам пользователей операционной системы на данном компьютере. По третьему пути должны располагаться модули, которые поставляются с операционной системой.
Таким образом, обычно пользователь должен устанавливать новые модули либо по первому пути, либо по второму пути (во втором случае — если он хочет, чтобы установленным модулем могли пользоваться все пользователи данного компьютера). Если вы устанавливаете новый модуль (или обновление) через саму программу «Windows PowerShell», то она не спрашивает, куда устанавливать модуль, а по умолчанию установит его либо по первому пути, либо по второму пути.
Установка и импорт модуля
Готовые модули разных версий обычно хранятся в репозиториях (базах данных) в интернете. Но, конечно, любой сайт может распространять модуль, ведь это всего лишь набор файлов. С точки зрения программы «Windows PowerShell» каждый модуль на своем пути из репозитория в интернете до введения в работу на компьютере пользователя должен пройти два этапа:
1) Установка (скачивание из интернета) модуля на компьютер;
2) Импорт модуля (или отдельных команд из модуля) в текущую сессию программы «Windows PowerShell». То есть импорт производится каждый раз при запуске новой сессии программы «Windows PowerShell».
Под установкой модуля в данном случае подразумевается закачка файлов модуля из репозитория в интернете на компьютер пользователя, создание папки модуля по одному из вышеуказанных путей и запись скачанных файлов модуля в созданную папку модуля.
Но установка модуля — это только первый этап. Хотя программа «Windows PowerShell» может видеть (может найти) установленный модуль, если он записан в папку, расположенную по одному из вышеуказанных путей. Для просмотра всех модулей (в том числе установленных, но не импортированных) можно использовать следующую команду:
Get-Module -list
Эта же команда, но без параметров, даст список только импортированных в текущую сессию работы программы «Windows PowerShell» модулей.
До третьей версии программы «Windows PowerShell», чтобы использовать команды из установленного модуля, следовало «импортировать» весь модуль или отдельные команды из него в текущую сессию работы программы «Windows PowerShell» (импорт проводится для каждой новой сессии работы программы «Windows PowerShell»). Импорт возможен, только если программа «Windows PowerShell» «видит» (может найти) запрашиваемый модуль. А видит она его только тогда, когда он расположен по одному из вышеприведенных путей. Понятно, что программа «Windows PowerShell» может «видеть» (может найти) только установленные на компьютер модули (она не может видеть модули, распложенные в репозитории в интернете).
Для свежих версий программы «Windows PowerShell» (в том числе для версии 5.1) производить импорт модуля в текущую сессию работы программы «Windows PowerShell» вручную, с помощью специальной команды Import-Module , не нужно. Теперь это делается автоматически, если вы запустили на выполнение команду из этого модуля. При запуске неизвестной команды программа «Windows PowerShell» просматривает установленные модули, находит модуль с нужной командой и импортирует этот модуль в свою текущую сессию работы.
Из-за этого результат работы команды Get-Module (без параметров) может меняться в течение одной сессии работы программы «Windows PowerShell». Список импортированных в текущую сессию работы модулей может постепенно увеличиваться, если пользователь использует в своей работе команды из разных модулей, которые в начале сессии еще не были импортированы.
Команда Import-Module в свежих версиях программы «Windows PowerShell» может понадобиться, только если вы хотите импортировать модуль, расположенный не по путям, прописанным в переменной $Env:PSModulePath (такие модули, как уже говорилось раньше, программа «Windows PowerShell» по умолчанию не «видит»).
Advanced PowerShell vol. 1: повторное использование кода
Привет! Как большой поклонник и активный практик PowerShell я часто сталкиваюсь с тем, что мне необходимо повторно использовать ранее написанные куски кода.
Собственно, для современных языков программирования code reuse — это обычное дело.
PowerShell в этом вопросе не отстает, и предлагает разработчикам (написателям скриптов) сразу несколько механизмов обращения к написанному ранее коду.
Вот они по возрастанию сложности: использование функций, дот-сорсинг и написание собственных модулей.
Рассмотрим их все порядку.
В качестве решения лабораторной задачи напишем скрипт, который расширяет раздел C:\ до максимально возможного размера на удаленном Windows-сервере LAB-FS1.
Такой скрипт будет состоять из одной строки и выглядеть так:
Invoke-Command -ComputerName LAB-FS1 -ScriptBlock
Работает это так. Сначала PowerShell устанавливает удаленное соединение с сервером LAB-FS1 и запускает на нем локально набор команд, заключенный в фигурные скобки параметра -ScriptBlock. Этот набор в свою очередь последовательно передает команде diskpart три текстовых параметра, а diskpart выполняет (по очереди) повторное сканирование разделов, выбор раздела C:\ и расширение его до максимально возможного размера.
Как видите, скрипт крайне простой, но в то же время крайне полезный.
Рассмотрим, как правильно упаковать его для повторного использования.
1. Использование функций
Самый простой вариант.
Предположим, что мы пишем большой скрипт, в котором нам по разным причинам необходимо много раз запускать расширение разделов на разных серверах. Логичнее всего выделить весь этот скрипт в отдельную функцию в этом же .ps1-файле и в дальнейшем просто вызывать ее по необходимости. Помимо этого мы расширим функционал скрипта, позволив администратору явно указывать имя удаленного сервера и букву расширяемого раздела. Имя и букву будем передавать с помощью параметров.
Функция и ее вызов будут выглядеть так:
function ExtendDisk-Remotely < param ( [Parameter (Mandatory = $true)] [string] $ComputerName, [Parameter (Mandatory = $false)] [string] $DiskDrive = "c" ) Invoke-Command -ComputerName $ComputerName -ScriptBlock > ExtendDisk-Remotely -ComputerName LAB-FS1 Здесь для функции ExtendDisk-Remotely заданы два параметра:
- Обязательный ComputerName;
- Необязательный DiskDrive. Есть не задать имя диска явным образом, скрипт будет работать с диском C:\
Сохраним скрипт под именем Example-01-Functions.ps1 и запустим:
Видим, что наша функция успешно вызвалась и расширила раздел C:\ на сервере LAB-FS1.
2. Дот-сорсинг
Усложняем ситуацию. Наша функция по расширению разделов оказалась так хороша, что мы хотим прибегать к ее использованию и в других скриптах. Как быть?
Копировать текст функции из исходного .ps1-файла и вставлять ее во все необходимые? А если код функции регулярно обновляется? А если эта функция нужна сотне скриптов? Очевидно, надо выносить ее в отдельный файл и подключать по мере необходимости.
Создадим отдельный файл для всех наших функций и назовем его Example-02-DotSourcing.ps1.
Его содержимое будет таким:
function ExtendDisk-Remotely < param ( [Parameter (Mandatory = $true)] [string] $ComputerName, [Parameter (Mandatory = $false)] [string] $DiskDrive = "c" ) Invoke-Command -ComputerName $ComputerName -ScriptBlock > Это объявление функции (без вызова), которая теперь хранится у нас в отдельном файле и может быть вызвана в любой момент с помощью техники, которая называется dot-sourcing. Синтаксис выглядит так:
. C:\Scripts\Example-02-DotSourcing.ps1 ExtendDisk-Remotely LAB-FS1 Внимательно посмотрите на первую строку кода и проанализируйте ее содержимое: точка, пробел, путь к файлу с описанием функции.
Такой синтаксис позволяет нам подключить к текущему скрипту содержимое файла Example-02-DotSourcing.ps1. Это то же самое, что использовать директиву #include в C++ или команду using в C# — подключение кусков кода из внешних источников.
После подключения внешнего файла мы уже во второй строке можем вызвать входящие в него функции, что мы успешно и делаем. При этом задотсорсить внешний файл можно не только в теле скрипта, но и в «голой» консоли PowerShell:
Техникой дотсорсинга можно пользоваться, и она будет у вас работать, однако гораздо удобнее пользоваться более современным способом, который мы рассмотрим в следующем разделе.
3. Написание собственного модуля PowerShell
Внимание: Я использую в работе PowerShell версии 4.
Одна из его особенностей заключается в том, что он автоматически подгружает в оперативную память модули по мере обращения к ним, без использования командлета Import-Module.
В старых версиях PowerShell (начиная с 2) написанное ниже будет работать, но может потребовать дополнительных манипуляций, связанных с предварительным импортом модулей перед их использованием.
Мы же будем рассматривать современные среды.
Усложняем ситуацию еще раз.
Мы стали очень хорошими PowerShell-программистами, написали сотни полезных функций, для удобства использования разделили их на десятки .ps1-файлов, и в нужные нам скрипты дотсорсим нужные файлы. А если у нас десятки файлов для дотсорсинга и их надо указать в сотне скриптов? А если мы несколько из них переименовали? Очевидно, что придется менять путь ко всем файлам во всех скриптах — это страшно неудобно.
Независимо от того, сколько функций для повторного использования вы написали, пусть даже одну, сразу оформляйте ее в отдельный модуль. Написание собственных модулей — это самый простой, лучший, современный и грамотный метод повторного использования кода в PowerShell.
Что такое модуль Windows PowerShell
Модуль Windows PowerShell — это набор функционала, который в том или ином виде размещен в отдельных файлах операционной системы. Например, все родные Микрософтовские модули являются бинарными и представляют собой скомпилированные .dll. Мы же будем писать модуль скриптовый — скопируем в него код из файла Example-02-DotSourcing.ps1 и сохраним как файл с расширением .psm1.
Чтобы понять, куда сохранять, посмотрим содержимое переменной окружения PSModulePath.
Видим, что по умолчанию у нас есть три папки, в которых PowerShell будет искать модули.
Значение переменной PSModulePath можно редактировать с помощью групповых политик, задавая таким образом пути к модулям для всей сети, но это другая история, и рассматривать ее сейчас мы не будем. Зато будем работать с папкой C:\Users\Administrator\Documents\WindowsPowerShell\Modules и сохраним наш модуль в нее.
Код остается неизменным:
function ExtendDisk-Remotely < param ( [Parameter (Mandatory = $true)] [string] $ComputerName, [Parameter (Mandatory = $false)] [string] $DiskDrive = "c" ) Invoke-Command -ComputerName $ComputerName -ScriptBlock > Меняется лишь папка, в которую сохраняется файл, и его расширение.
Очень важно!
Внутри папки Modules необходимо создать подпапку с именем нашего модуля. Пусть этим именем будет RemoteDiskManagement. Сохраняем наш файл внутрь этой подпапки и даем ему точно такое же имя и расширение .psm1 — получаем файл C:\Users\Administrator\Documents\WindowsPowerShell\Modules\RemoteDiskManagement\RemoteDiskManagement.psm1.
Наш модуль готов, и мы можем проверить, что он виден в системе:
Модуль виден, и в дальнейшем мы можем вызывать его функции без предварительного объявления их в теле скрипта или дотсорсинга.
PowerShell будет воспринимать нашу функцию ExtendDisk-Remotely как «встроенную» и подключать ее по мере необходимости:
На этом всё: мы можем написать десятки собственных модулей, править код включенных в них функций и использовать их в любой момент, не думая о том, в каком скрипте необходимо поменять название функции или путь к дотсорсному файлу.
4. Другие advanced-возможности
Как я уже писал, я люблю PowerShell, и если сообществу интересно, могу написать еще с десяток статей о его расширенном функционале. Вот примеры тем для обсуждения: добавление справки к написанным функциям и модулям; как заставить вашу функцию принимать значения из конвейера и какие это особенности это накладывает на написание скрипта; что вообще такое конвейер и с чем его едят; как с помощью PowerShell работать с базами данных; как устроены расширенные функции и какими свойствами могут обладать их параметры и т.д.
Интересно?
Тогда попробую выдавать по одной статье в неделю.
- powershell
- windows server
An Introduction to PowerShell Modules
For PowerShell to provide specialised scripting, especially for administering server technologies, it can have the range of Cmdlets available to it extended by means of Snapins. With version 2 there is an easier and better method of extending PowerShell: the Module. These can be distributed with the application to be administered, and a wide range of Cmdlets are now available to the PowerShell user. PowerShell has grown up.
One of the great features of PowerShell is its extensibility. In PowerShell version 1 it was possible for other product teams within Microsoft or elsewhere to use a delivery mechanism known as snap-ins to extend PowerShell with additional PowerShell cmdlets. Although the snap-in mechanism is still supported within PowerShell version 2, the new feature known as a PowerShell module has made it much easier to extend PowerShell to make it more appropriate for specialised uses.
PowerShell modules bring extendibility to the systems administrator, DBA, and developer. Whether it’s simply as a method to share functions and scripts you have created or delving further into providing what would have been snap-in territory in version 1, you should be aware of the capabilities of modules.
PowerShell is an integral part of Windows 7 and Windows Server 2008 R2. Window Server 2008 R2 ships with a number of built-in modules. Further modules become available after installing various additional components of the operating system.
In this article we will examine the fundamentals of modules and then, by way of an example, look at some practical ways you can make use of them in Windows Server 2008 R2.
PowerShell Modules
in PowerShell version 1, Snap-ins were popular with systems administrators who used cmdlets provided by third parties, such as Quest’s Active Directory cmdlets and VMware’s PowerCLI cmdlets. However, you did not find many of those same administrators creating their own snap-ins, particularly if they were just starting out learning PowerShell because it would typically involve writing some C# code.
PowerShell version 2 makes it easier to achieve the objective of sharing functions and scripts as part of a module. In addition, whilst a snap-in can only contain cmdlets and providers, a module can also contain other common PowerShell items such as functions, variables, aliases and PowerShell drives.
Creating Your First PowerShell Module
Before you create your first PowerShell Module you will need to know what to create and where to store it. PowerShell will look in the paths specified in the $env:PSModulePath environment variable when searching for available modules on a system. By default this contains two paths; one in a system location %windir%\System32\WindowsPowerShell\v1.0\Modules and also in the currently logged on user location %UserProfile%\Documents\WindowsPowerShell\Modules . In this article for the sake of convenience we will store our module in the %UserProfile% location.
Each module should be stored in a sub folder of either of these paths and typically be the name of the module – within that folder you will then store the files that make up the module. At the least, we need a *.psm1 file. In this file could be placed a number of functions or variables that make up the module. In addition it is possible to place PowerShell scripts in *.ps1 files in the module’s folder and reference them in the *.psm1 file. As a final touch, a module manifest file can be created which will give a more professional and rounded feel to your module, but we will come on to manifests later.
Let’s look at the process of creating an example module.
To start with we will place a couple of functions in a *.psm1 file to make the module. There is nothing special in a *.psm1 file other than the file extension, so we can take a normal *.ps1 PowerShell script file containing our functions and rename it to make the *.psm1 file.
При подготовке материала использовались источники:
https://ilyachalov.livejournal.com/224744.html
https://habr.com/ru/articles/245875/