 |
|
|
|
Осваиваем нововведения языка сценариев Windows PowerShell 2.0
Осваиваем нововведения Приближается долгожданное событие – выход Windows PowerShell 2.0. Что принесёт изменение цифры в версии молодого языка сценариев? С одной стороны, синтаксис языка практически не претерпел изменений, переучиваться не придётся – сценарии, написанные для PowerShell 1.0, будут прекрасно работать и в PowerShell 2.0. С другой стороны, приятных нововведений так много, что я сразу предупреждаю – рассказать обо всех в одной статье невозможно. Так что я сделаю лишь краткий обзор нового функционала. Компонент системы PowerShell 2.0 сначала появится в составе операционных систем Windows 7 и Windows Server 2008 R2. Это значительный шаг для молодого языка сценариев, ведь теперь он является неотъемлемым компонентом системы. Да что там говорить, в Windows Server 2008 R2 значок PowerShell вынесен на панель задач сразу после Server Manager! И это не просто из-за того, что Microsoft хочет продвинуть новую технологию – немало функционала в новых системах основано на PowerShell. Взамен же PowerShell предоставляет богатые возможности по управлению различными компонентами этих систем. Кроме того, теперь вы сможете легко использовать PowerShell в групповых политиках, будучи уверены в том, что он установлен на системе, и сценарий будет выполнен. Отдельная ситуация с Server Core. Несмотря на то что PowerShell теперь официально поддерживается в этом режиме установки системы, по умолчанию он не установлен, и это связано с самой идеологией Server Core – минимум всего. Но несмотря на это, установить PowerShell в Server Core несложно, за пару минут, одной командой: start /w ocsetup MicrosoftWindowsPowerShell Удалённое выполнение команд (Remoting) Одна из самых ожидаемых возможностей Windows PowerShell 2.0 – это, конечно, Remoting. Стоит, однако, заметить, что в это понятие авторы PowerShell вкладывают гораздо больший смысл, нежели «запустить команду на другом компьютере». PowerShell Remoting позволит вам не просто выполнять команды на одном или нескольких удалённых компьютерах, но и отслеживать их выполнение и получать результаты их работы. Причем это обычно для PowerShell и необычно для остальных – результаты работы по сети будут передаваться не в виде простого текста, а в виде объектов. Разумеется, многие объекты потеряют некоторые качества в отрыве от систем, на которых они были созданы, – все их методы будут удалены. Но свойства останутся (и даже будут добавлены новые, такие как PSComputerName, указывающий, с какого компьютера был получен объект), и с ними можно будет работать, как с остальными объектами PowerShell. Гибкость Remoting тоже не разочарует. Можно как выполнять отдельные команды, так и установить постоянную сессию или сессии на несколько компьютеров, и выполнять в них серии команд. Это позволит, во-первых, сэкономить ресурсы за счет того, что не будет создаваться и уничтожаться отдельное окружение PowerShell для каждой команды, а во-вторых, команды из последовательности будут иметь доступ к переменным и другим объектам, созданным в этой сессии предыдущими командами. Если вы захотите использовать интерактивные сессии, как в Telnet, SSH или PSExec, то возможно и это с помощью командлета Enter-PSSession (см. рис. 1, 2).
Рисунок 1. Использование интерактивной сессии PowerShell Remoting
Рисунок 2. PowerShell Integrated Scripting Environment (ISE) Разумеется, Remoting отключён на системах по умолчанию. Хоть это и прекрасное средство управления, безопасность остаётся превыше всего. Впрочем, включить его несложно, достаточно выполнить командлет Enable-PSRemoting, который спросит подтверждение (от которого можно избавиться с помощью ключа Force) и затем выполнит все необходимые действия для предоставления удалённого доступа для учетных записей, являющихся администраторами компьютера. Этот метод хорош, когда вам надо включить Remoting на одном или нескольких компьютерах, но что делать, если их десятки, сотни, тысячи? Всего лишь несколько дополнительных манипуляций. Все действия, что производит командлет Enable-PSRemoting, можно сделать с помощью групповой политики. Во-первых, надо включить настройку Computer Configuration/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service/Allow automatic configuration of listeners. В ней же можно задать диапазоны адресов, с которых разрешены подключения. Во-вторых, нужно создать необходимые исключения в брандмауэре Windows. Ну и наконец, установить для службы Windows Remote Management (WS-Management) автоматический режим запуска. Так как PowerShell Remoting использует технологию WinRM (реализацию стандарта WS-Management), он наследует множество её преимуществ. Например, возможность подключаться к системам даже через прокси-серверы. Или выдающаяся безопасность – все соединения Remoting шифруются в обязательном порядке, с использованием SSL. Разумеется, шифруются и передаваемые учетные данные. Кстати, поддерживается несколько механизмов аутентификации – Kerberos, NTLM, Digest и Basic. Разумеется, самым безопасным является Kerberos и по умолчанию, при возможности используется именно он. По умолчанию подключение можно установить, лишь используя учетную запись, обладающую правами администратора на удаленном компьютере. Но вы вполне можете изменить эти разрешения или даже создать отдельные конфигурации подключений для разных групп пользователей. У разных конфигураций – разные ограничения. Лимитирование объема передаваемых данных или времени выполнения команд позволит в некоторой степени защититься от пожирания ресурсов сервера одним чересчур активным пользователем. Но главное это, конечно, возможность ограничить список разрешенных команд, их параметров и конструкций языка. То есть вы можете разрешить определенной группе пользователей выполнять на сервере лишь командлеты Get-* для получения информации, но внести в систему изменения они не смогут. Другой группе можно дать право исполнения командлета Get-Process с параметром -Id, а все остальные параметры и команды будут недоступны. За другими подробностями можно обратиться во встроенную справку, выполнив команду: help about_remoting Фоновые работы (Jobs) Не менее важно и другое нововведение – фоновые работы. Те, кто работал с UNIX-подобными системами, наверняка знают, что это такое, для остальных же поясню. Это команды, которые выполняются в отдельной сессии, параллельно основной. То есть вы можете запустить команду, требующую много времени, в качестве фоновой работы, и продолжать заниматься другими делами. Можно просматривать статус выполнения работ и при необходимости получать их результаты. В PowerShell 2.0 это реализуется с помощью командлетов с существительным Job, которое позволяет: Start-Job – запустить новую работу. Get-Job – получить список работ текущей сессии и посмотреть их статус. Receive-Job – получить результаты выполнения команды. Стоит обратить внимание, что после того как Receive-Job передаст вам данные, она тут же уберёт их из стека вывода работы, и, вызвав командлет второй раз, вы получите лишь новые данные. Чтобы этого не происходило, используйте ключ Keep. Впрочем, я не буду рассказывать о действии каждого командлета *-Job, уверен, вы прекрасно справитесь сами с помощью встроенной справки. Лучше упомяну о другом методе запуска фоновых работ, параметре -AsJob. Он присутствует у многих разных команд. Например, Invoke-Command -AsJob позволит вам запустить продолжительную команду на нескольких компьютерах в виде работ, а затем отслеживать процесс их выполнения и результаты с помощью командлетов *-Job. Get-WmiObject -AsJob делает примерно то же самое, но для WMI-запросов. Например, эта команда запрашивает значение Win32_ComputerSystem для всех компьютеров из списка Computers.txt, но не более чем на двух одновременно. PS C:\> $Comps = Get-Content Computers.txt PS C:\> $Job = Get-WmiObject Win32_ComputerSystem `
PS C:\> $job.ChildJobs
Результаты, разумеется, можно получить командлетом Receive-Job. Раздел справки, посвященный фоновым работам, – About_Jobs. ISE Хоть появление графической оболочки и среды разработки для PowerShell и не является прорывом (уже давно существует немало решений от сторонних производителей), тем не менее ISE всё-таки принесёт немало полезных нововведений. Во-первых, это полноценный интерпретатор PowerShell, подобный самому PowerShell.exe, но в отличие от него не использующий консольную подсистему Windows, которая не изменялась уже много лет. Это даёт прекрасную возможность начать всё сначала и не повторять ошибок прошлого. PowerShell ISE не испытывает вообще никаких проблем с отображением Unicode и любых локальных символов. Текст можно удобно выделять, копировать и вставлять, как в любом другом приложении Windows. Разумеется, нет никаких сложностей с изменением размеров окна, это делается лишь перетаскиванием края окна, без необходимости залезать в какие-либо настройки. Также легко можно поменять размер шрифта. Кажущаяся обычной подсветка синтаксиса всё же отличается от аналогичной в других продуктах тем, что для разбора текста сценариев и команд используется оригинальный механизм PowerShell, а не сложные правила, пытающиеся повторить его функционал. Теперь вы можете быть уверены – если редактор не подсвечивает какой-то участок или подсвечивает его не так, как вы хотите, значит, где-то вкралась ошибка. Разумеется, работает и автоматическое дополнение команд, параметров, переменных и свойств объектов, так же как и в обычном PowerShell.exe. Причем для этого также используется обычная функция TabExpansion, а следовательно, стандартный функционал можно расширить. Вполне естественным для такого редактора выглядит и наличие прекрасного отладчика с возможностью установки точек останова, просмотра содержимого переменных в процессе выполнения и всего остального, что может пригодиться для поиска ошибок при выполнении сценария. Кроме обычных, для многих текстовых редакторов закладок, в которых можно открыть разные текстовые файлы, в PowerShell ISE можно еще открывать отдельные сессии PowerShell, не соприкасающиеся друг с другом. А благодаря технологии Remoting некоторые из этих сессий могут выполняться даже на других компьютерах! Но главный момент для графической среды разработки – это, конечно, удобство. В PowerShell ISE вы можете выбрать расположение панелей редактора, командной строки и области вывода результатов. Можно даже скрыть всё, кроме редактора, и полностью погрузиться в процесс разработки своего сценария (см. рис. 3).
Рисунок 3. Результат работы командлета Out-GridView Если бы этим редактор ограничивался, он бы не смог стать хорошей альтернативой конкурентам. Но, к счастью, ISE обладает прекрасными возможностями для расширения своего функционала... с помощью сценариев PowerShell! С помощью специальной переменной $PsIse можно получить доступ к управлению интерфейсом PowerShell ISE, добавить свои пункты меню, обрабатывать текст из панелей редактора и командной строки и так далее. Я уверен, что вскоре после релиза появится множество пользовательских сценариев, приумножающих функционал ISE. Соответствующий раздел справки называется about_Windows_PowerShell_ISE. Advanced Functions Те, кто серьезно занимался написанием своих сценариев или создавал командлеты в Windows PowerShell 1.0, наверняка обратили внимание на то, что у последних есть некоторые достаточно большие преимущества. Так, например, в сценарии .ps1 вы не сможете использовать несколько различных наборов параметров, создавать для параметров псевдонимы и указывать другие атрибуты, такие как ValueFromPipeline и ValidateSet. Даже использование специальных параметров -WhatIf и -Confirm было невозможным в обычных файлах сценариев, лишь в командлетах, написанных на C# или VB.Net. Что ж, теперь все будут находиться в равных условиях. Командлеты, написанные непосредственно на PowerShell, называются Advanced Functions, их синтаксис лишь немного отличается от обычных функций, но зато даёт гораздо большие возможности для создания качественных сценариев для долговременного использования. Подробности в about_functions_advanced. Встроенный отладчик По мне, и в PowerShell 1.0 была прекрасная возможность отладки сценариев из командной строки, которой могли позавидовать многие языки сценариев. Достаточно было добавить в текст сценария строку $Host.EnterNestedPrompt(), и при её достижении сценарий приостанавливался, предоставляя вложенную консоль, из которой можно было посмотреть и даже изменить состояние переменных, попробовать выполнить команду вручную и т.п. Для выхода достаточно было набрать Exit. Но в 2.0 консольный отладчик вышел на совершенно новый уровень. Теперь можно создавать точки останова, которые будут срабатывать не только на некоторых строках, но и по достижении определенного столбца, команды или файла сценариев или переменной. Причем для последних можно задать, при каких действиях над переменной нужно срабатывать: чтение значения из переменной, изменение значения или и то и другое. Есть возможность создать точки останова, которые вместо прерывания выполнения, будут выполнять любое указанное вами действие. При срабатывании точки останова консоль переходит в специальный режим отладки, который можно отличить по префиксу [DBG]: в приглашении командной строки. Тут доступны специфичные для данного режима команды: stepInto, stepOver, stepOut, continue, list и некоторые другие, которые вы можете посмотреть, введя в командную строку вопросительный знак и нажав <Enter>. Управляют точками останова с помощью командлетов *-PSBreakpoint. Для переключения различных опций, относящихся к режиму отладки, служит командлет Set-PSDebug. Кроме того, выполнив этот командлет с ключом -Strict, вы включите Strict Mode, специальный режим, аналогичный Option Explicit в Visual Basic. Еще много интересного об отладке вы сможете прочитать в разделе встроенной справки about_Debuggers. Новые командлеты В PowerShell 2.0 добавилось множество новых командлетов. Я кратко расскажу о наиболее интересных. Командлет Add-Type пригодится для использования в сценарии кода других .Net-языков. Это бывает очень полезно, если какая-то операция в сценарии должна выполняться максимально быстро или если вдруг вам понадобится какая-то из возможностей этих языков, которая недоступна в PowerShell. Например, Win32 API. Это низкоуровневые функции для управления различными аспектами системы, зачастую с их помощью можно сделать вещи, недоступные иными методами. Вот простой пример вызова функции Win32API Show-WindowAsync: $type = Add-Type @" [DllImport("user32.dll")] public static extern bool ShowWindowAsync(IntPtr hWnd, int nCmdShow); "@ -name "Win32ShowWindowAsync" -namespace Win32Functions -passthru #Скрывает окно PowerShell $type::ShowWindowAsync((get-process -id $pid).MainWindowHandle,2) #Снова показывает окно $type::ShowWindowAsync((get-process -id $pid).MainWindowHandle,10) Определения других функций Win32 API вы можете посмотреть на сайте http://www.pinvoke.net. Команда разработчиков PowerShell, видимо, решила прибрать к рукам большую часть функционала утилиты net.exe, создав соответствующие командлеты, и это здорово! Просто посмотрите на названия командлетов, уверен, что мне не придётся объяснять их назначение:
Еще больше команд появилось для работы с журналами событий Windows:
С их помощью легко производить любые операции с журналами, например, создать для своего сценария журнал событий, установить его параметры и записывать в него отладочную информацию. Согласитесь, ведь текстовые журналы мы использовали лишь из-за того, что это было проще. Теперь также просто использовать системный функционал, предназначенный специально для этого. Журналы событий можно легко фильтровать, передавать на другой компьютер с помощью подписок или отслеживать, используя решения, подобные SC Operations Manager. Отдельно стоит упомянуть командлет Get-WinEvent. Он работает только на системах Windows Vista, Windows Server 2008 и выше из-за того, что использует новые возможности механизма журналов событий. Кроме обычного извлечения событий, соответствующих вашим критериям из журнала, он может, например, показать список зарегистрированных в системе поставщиков событий и события, которые они могут писать: $Provider = Get-WinEvent -ListProvider *update* $Provider.Events | Format-Table Id, description -AutoSize Чтобы увидеть другие примеры применения этого командлета, рекомендую вызвать команду: Get-Help Get-WinEvent -Examples Их там весьма немало. Командлеты для работы с журналами событий легко спутать с другим набором команд. Эти предназначены для привязки своих действий к событиям, вызываемым другими объектами .Net или WMI:
С их помощью можно, например, сделать, чтобы в созданной вами форме при нажатии на кнопку выполнялась ваша команда. Или назначить выполнение своего сценария на событие создания определенного файла в определенной папке, тогда вам не придется постоянно проверять список файлов – система сама оповестит сценарий при изменениях. Или вызывать код при завершении/старте процесса Windows. Get-Counter даст возможность легко и непринуждённо получать данные различных счетчиков производительности Windows. Ну и как можно догадаться, Export-Counter и Import-Counter позволяют экспортировать показания этих счетчиков и импортировать их в другую сессию для анализа. Пусть в PowerShell 1.0 и так было несложно получить произвольное число или выбрать уникальное значение из группы, в 2.0 это стало еще проще и удобнее благодаря командлетам Get-Random и Get-Unique. Воспользоваться всеми благами новой технологии веб-служб позволит командлет New-WebServiceProxy, который может подключаться к соответствующим сервисам и управлять ими или получать данные. Out-GridView – командлет, который выводит возможности PowerShell за пределы командной строки. Он может показать данные, полученные по конвейеру в виде красивой и удобной таблицы, в которой работает мгновенный поиск, и можно даже фильтровать показанные результаты с помощью графического интерфейса для создания правил отбора. Функционал командлетов Send-MailMessage и Test-Connection вряд ли кого-то удивит. Первый позволяет отправлять почтовые сообщения по протоколу SMTP, а второй является аналогом Ping для PowerShell с массой новых возможностей, таких как многопоточность или выполнение пинга с другого компьютера. Подробно обо всех этих командах можно прочитать во встроенной справке, вызвав ее следующей командой: Help ИмяКомандлета Чтобы увидеть примеры использования, добавьте ключ Examples, а для просмотра максимально полной версии справки с описанием всех параметров и примерами – ключ Full. Новые параметры у старых команд В процессе добавления новых команд не были забыты и старые друзья. Хотя основной функционал старых командлетов почти не изменялся для сохранения совместимости, ко многим командлетам были добавлены новые параметры, расширяющие их возможности. Import-Csv и Export-Csv получили крайне необходимые в российских условиях параметры -Delimiter и -UseCulture, позволяющие задать используемый разделитель символов. Командлет Get-Help, если не находит команды или раздела справки соответствующего переданному аргументу, выполняет поиск упоминаний этого аргумента по всем разделам. Попробуйте выполнить, например, команду: Get-Help "regular expression" и вы увидите все разделы справки, где упоминаются регулярные выражения. Новый параметр командлета Select-String -Context позволяет получить не только ту строку, в которой было найдено вхождение искомого текста, но и несколько предыдущих и/или последующих строк. Например, следующая команда выведет все строки, в которых встречается слово Error, одну предыдущую строку и две последующие: Get-Content Log.txt | select-string "Error" -Context 1,2 Другие улучшения языка Как я уже сказал, в статье не хватит места рассказать обо всех нововведениях, и, разумеется, я не упомянул о многих новых командах и улучшениях, но некоторые вещи заслуживают хотя бы пары слов. Так, теперь вы можете использовать в своих сценариях Windows Presentation Foundation, технологию возможности которой для простого создания красивых графических интерфейсов уже оценили многие Windows-программисты. В PowerShell 2.0 вы сможете легко создавать обертки для команд, добавляя/изменяя/удаляя параметры, при этом сохраняя оригинальный функционал команды. Пример можно посмотреть в блоге разработчиков http://blogs.msdn.com/powershell/archive/2009/03/13/dir-a-d.aspx. Благодаря новому подъязыку – data language – будет легко создавать сценарии, говорящие на разных языках, или отделить в сценарии данные от исполняемого кода. Модули позволят хранить, распространять и подключать ваши наборы функций с гораздо большим удобством. О них можно прочитать в разделе справки About_Modules. Другой раздел, About_Transactions, поведает вам о технологии, которая впервые появилась в языках сценариев, и даст нам совершенно новые возможности. Оператор -Split легко разделит строку на компоненты, а -Join соберет ее заново, и все это используя указанные вами разделители. Конструкция Try Catch Finally сделает обработку ошибок приятным делом. Если вы не знакомы с ней по другим языкам, то сможете научиться ее использовать, прочитав раздел справки about_Try_Catch_Finally. Используя добавившиеся во второй версии многострочные комментарии, вы сможете легко создавать полноценную справку для своих сценариев и функций. Затем конечный пользователь сможет увидеть эту справочную информацию, даже не заглядывая в исходный код сценария, с помощью командлета Get-Help. Кстати, о справке, не поленитесь и вызовите команду: Get-Help about_* В PowerShell 2.0 было добавлено много новых разделов, которые позволят узнать еще больше о функционале этого языка и дадут вам еще больше возможностей. Что дальше? Рекомендую вам не останавливаться после прочтения этой статьи. Загрузите PowerShell 2.0 и попробуйте нововведения самостоятельно. Хоть доступная на момент написания статьи версия CTP3 и не рекомендуется к применению в реальном окружении, надо заметить, что она достаточно стабильна. Для использования Remoting и фоновых работ понадобится установить еще и WinRM 2.0 CTP3, который пока распространяется отдельно. Ссылки на загрузку находятся тут – http://xaegr.wordpress.com/2008/12/24/powershell-20-ctp3. Если же, когда вы будете читать эту статью, уже появится финальная версия PowerShell 2.0, то вы наверняка сможете его загрузить со страницы http://microsoft.com/powershell/download. Впрочем, если вы используете Windows 7, или Windows Server 2008 Release Candidate, или финальную версию, то вам не стоит себя утруждать никакими загрузками – PowerShell 2.0 и WinRM 2.0 уже интегрированы в эти системы. Ну и конечно, не забывайте посещать мой блог (http://xaegr.wordpress.com) и блог команды разработчиков PowerShell (http://blogs.msdn.com/powershell), где вы найдете множество информации о PowerShell 2.0 и примеров кода. Также существует русскоязычная версия блога команды PowerShell – http://blogs.technet.com/powershell_ru. Еще обязательно загляните на TechDays.Ru, там уже накопилось немало видеодокладов, посвященных PowerShell – http://www.techdays.ru/Category.aspx?Tag=PowerShell. |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
