Телефон +7 (812) 718-6184
СПб, Московский пр. 118
  1. О центре
  2. Статьи преподавателей
  3. Powershell - как инструмент администратора

Powershell - как инструмент администратора

17.10.2019

Краткая вводная
Откуда
В конце 2007-го года компания Microsoft представляет миру ИТ консоль управления. Специалисты компании заверяют, что это принципиально новая консоль, которая позволит быстро решить администратору значительную часть рутинных и/или сложных задач с меньшими трудозатратами. Клавиша «Счастье».
Для чего
Различные производители выпускают автоматизированные системы управления, предназначенные разрешать типовые задачи ИТ персонала. И по большей части эти системы справляются с поставленными задачами, кроме тех случаев, когда задача уникальна, а её решение адаптировано под требования конкретной организации.
Какие задачи решает
Вот в этом случае PowerShell позволяет раскрыть весь свой потенциал, начиная от написания своих функций и классов и заканчивая использование подключаемых бинарных библиотек, а, так же, использование некоторых языков программирования прямо в коде скрипта.
На данный момент PowerShell является открытым проектом (opensource) и становиться интересным как основной инструмент управления в смешанных системах. В текущий момент доступны следующие выпуски, в том числе, и последние:

Нелегкий путь от командлета к рабочему модулю
Одна из проблем, с которой сталкиваются многие специалисты различного уровня, это правильное написание скриптов, функций и прочих инструментов. Вопросы касаются, как общих тем, так и узких тематик. Тем не менее есть ряд общих рекомендаций:

  • одна задача – один инструмент
  • гибкость применения
  • понятное название и область применения
  • функциональность

Разберем эти вопросы на примере решения задачи - функция смены «LogonName» у произвольного сервиса целевого хоста и оформим в виде отдельного модуля. Стандартные командлеты не позволяют сменить у сервиса имя для старта. Допустим у нас заготовлена сервисная учетная запись и необходимо веерно внести изменения в настройки сервисов на множестве хостов.
Cmd-let -> Script
Командлет находится достаточно быстро “Invoke-CimMethod”. Так же быстро находится и само решение:

Invoke-CimMethod -Query "SELECT * FROM Win32_Service WHERE Name=`'`'" -Method Change -Arguments , -Computername

Сохраняем, как *.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
Что не хватает и куда двигаться далее?

  1. Помощи. Внятной помощи по работающему инструменту с яркими примерами и описанием.
  2. В рамках типовых задач можно создать свой собственный класс или пространство классов.
  3. Модули есть смысл разместить в доверенных репозиториях компании и централизованно управлять ими.
  4. Типовые задачи можно делегировать младшему персоналу, используя механизмы JEA + JumpServer.

Все решение построено на информации из курсов по PowerShell:

  1. 10961 - Automating Administration with Windows PowerShell
  2. 10962 - Advanced Automated Administration with Windows PowerShell
  3. 55039 - Windows PowerShell Scripting and Toolmaking

Первые два курса предоставляют последовательной погружение в функционал PowerShell. Последний курс интересен подходом к разработке инструментов без акцента на базовом функционале.
P.S. код примеров доступен на GitHub
 

Подготовил Ростислав Бронзов