Powershell – это просто Краткая вводная Откуда В конце 2007-го года компания Microsoft представляет миру ИТ консоль управления. Специалисты компании заверяют, что это принципиально новая консоль, которая позволит быстро решить администратору значительную часть рутинных и/или сложных задач с меньшими трудозатратами. Клавиша «Счастье». Для чего Различные производители выпускают автоматизированные системы управления, предназначенные разрешать типовые задачи ИТ персонала. И по большей части эти системы справляются с поставленными задачами, кроме тех случаев, когда задача уникальна, а её решение адаптировано под требования конкретной организации. Какие задачи решает Вот в этом случае PowerShell позволяет раскрыть весь свой потенциал, начиная от написания своих функций и классов и заканчивая использование подключаемых бинарных библиотек, а, так же, использование некоторых языков программирования прямо в коде скрипта. На данный момент PowerShell является открытым проектом (opensource) и становиться интересным как основной инструмент управления в смешанных системах. В текущий момент доступны следующие выпуски, в том числе, и последние: Нелегкий путь от командлета к рабочему модулю Одна из проблем, с которой сталкиваются многие специалисты различного уровня, это правильное написание скриптов, функций и прочих инструментов. Вопросы касаются, как общих тем, так и узких тематик. Тем не менее есть ряд общих рекомендаций:
Разберем эти вопросы на примере решения задачи - функция смены «LogonName» у произвольного сервиса целевого хоста и оформим в виде отдельного модуля. Стандартные командлеты не позволяют сменить у сервиса имя для старта. Допустим у нас заготовлена сервисная учетная запись и необходимо веерно внести изменения в настройки сервисов на множестве хостов. Cmd-let -> Script Командлет находится достаточно быстро “Invoke-CimMethod”. Так же быстро находится и само решение:
Invoke-CimMethod -Query "SELECT * FROM Win32_Service WHERE Name=`'
Сохраняем, как *.ps1 и получаем рабочий скрипт. Конечно, необходимо знать, как запускать скрипты в среде PS, но это относиться скорее к вопросам безопасности, а не написанию самого скрипта. Подобный запрос будет работать и нас это устраивает. Script -> Param-script Работа с подобным скриптом не удобна, так как он позволяет решить только одну задачу и под каждый сервис его приходиться править. Следующий шаг, это использование параметризированного скрипта. Добавляем переменные и параметры в заголовок скрипта:
PARAM ( [string]$ServiceName="BITS", [string]$LogonName="LocalSystem", [string]$LogonPassword=$null, [string]$ComputerName="localhost" )
Теперь, если сделать запрос get-help “.\script.ps1”
Т.е. в скрипт можно передать данные, что позволяет влиять на результат не внося изменения, каждый раз. Param-script -> Function Далее, есть смысл оболочить скрипт в функцию и дать ей понятное имя. Существует принятые соглашения в среде пользователей PS – каждая команда должна соответствовать формуле «глагол-существительное». При этом глаголы допускаются из одобренного списка, который можно получить командлетом Get-Verb. Таким образом, наша функция должна получить название подобное Set-ServiceLogonName. И в данный момент начинается наиболее интересное, предполагается что функция будет работать подобно остальным, т.е. принимать данные по конвейеру и с командной строки. Стало быть, необходимо внести изменение в блок параметров и основной обработчик функции. Так же, чтобы наша функция могла взаимодействовать со стандартными параметрами системы необходимо добавить соответствующий ключ -“CmdletBinding”:
[CmdletBinding()] PARAM ( [parameter(Mandatory=$true,Position=0,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)] [string[]]$ServiceName="BITS", [string]$LogonName="LocalSystem", [string]$LogonPassword=$null, [parameter(Mandatory=$false,ValueFromPipeline=$false,ValueFromPipelineByPropertyName=$false)] [string]$ComputerName="localhost" )
Function -> PS Module Добро. Осталось только расположить функцию в модуле. Для этого сохраним полученное в каталоге «EUServiceMGMT» c именем «.\tools.psm1». Так же в этом каталоге должен быть расположен модуль-описатель «.\EUServiceMGMT.psd1», в который вносим техническую информацию по нашему модулю. А, так же, основной модуль-инициатор «.\root.psm1» с которого начинается загрузка на выполнение нашего модуля. В нём для примера расположены модификаторы рабочей среды. Что возвращает функция? В заключение функция возвращает объект, сформированный по окончании работы основного обработчика. В случае, если нам это не интересно, есть смысл подавлять вывод и формировать собственный. Правило хорошего тона рекомендуют возвращать код завершения, чаще всего это «0» в случае успеха. Return 0 Что не хватает и куда двигаться далее?
Все решение построено на информации из курсов по PowerShell:
Первые два курса предоставляют последовательной погружение в функционал PowerShell. Последний курс интересен подходом к разработке инструментов без акцента на базовом функционале. P.S. код примеров доступен на GitHub
Подготовил Ростислав Бронзов |