Windows PowerShell: Среда Windows PowerShell Workflow

Каждый месяц этого года Дон Джонc будет публиковать статьи из учебного курса по Windows PowerShell Workflow, состоящего из 12 частей. Мы рекомендуем читать их по порядку, начиная со статьи за январь 2013.

Дон Джонс

Как я писал в прошлом месяце, Windows PowerShell Workflow — нововведение Windows Management Framework версии 3. Он устанавливается вместе с Windows Server 2012 и Windows 8. Кроме того, он доступен для Windows 7, Windows Server 2008 и Windows Server 2008 R2. Для запуска рабочего процесса обязательно нужна одна из этих ОС. При этом адресатом рабочего процесса, т.е. системой, в которой запускаются задания, может быть любая версия Windows, в зависимости от того, какое именно задание вы пытаетесь выполнить.

Помимо стандартных системных требований Windows PowerShell версии 3, для работы с Windows PowerShell Workflow должны выполняться два основных требования. Во-первых, для того чтобы в оболочке было можно задействовать функции рабочих процессов, потребуется использовать модуль PSWorkflow, содержащий несколько командлетов. Во-вторых, на компьютерах, которые, как вы планируете, будут адресатами Windows PowerShell Workflow, потребуется активизировать Windows PowerShell Remoting.

Можно не запускать Remoting (удаленное выполнение) на компьютере, на котором вы выполняете рабочие процессы, но это обязательно нужно сделать на всех компьютерах, на которых вы планируете собирать информацию, выполнять настройку или осуществлять еще какое-либо управление. Windows PowerShell Workflow использует Remoting в качестве основного протокола взаимодействия. Наверно, можно написать кое-какие рабочие процессы, которым не нужен Remoting, но их будет совсем немного.

Remoting — совершенно недопонятый компонент Windows PowerShell. Во многих организациях специалисты по ИТ-безопасности применяют поход «не развертывать Remoting». Это досадная ошибка. Те же люди, озабоченные безопасностью, без проблем разрешают многие другие удаленные протоколы управления, такие как Remote Desktop Protocol (RDP), удаленные вызовы процедур (remote procedure calls, RPC) и HTTP.

Remoting — дальнейшее развитие механизмов обмена управляющей информацией в среде Windows. Вскоре Microsoft начнет консолидацию этих более старых протоколов в Remoting. Remoting использует HTTP и HTTPS, очень удобен для настройки и управления и его можно централизованно ввести в действие через объект групповой политики (Group Policy Object, GPO). Кроме того, он в целом более безопасен, более удобен для аудита и более управляем, чем эти старые протоколы. Чтобы ознакомиться с более полным исследованием того, как Remoting и его архитектура влияют на безопасность, скачайте мою бесплатную электронную книгу «Secrets of PowerShell Remoting».

Внутри рабочего процесса

Самая большая сложность, с которой вы столкнетесь в начале работы с Windows PowerShell Workflow, — усвоить, что хотя он выглядят как сценарий Windows PowerShell (а именно - функция), это нечто другое. «Язык Windows PowerShell», на котором вы пишете, транслируется во внешний язык (XAML). Затем код на этом языке выполняется в среде, отличной от Windows PowerShell.

В результате возникают кое-какие различия в правилах. Некоторые из них чисто синтаксические. Вообще говоря, вы должны использовать для выполняемых вами командлетов полные имена. Кроме того, не допускаются позиционные параметры и сокращенные имена параметров. Вы обязаны использовать полные имена параметров.

Более сложное для понимания отличие — среда рабочего процесса в целом. Основная особенность рабочего процесса — то, что его выполнение может прерываться и возобновляться по вашему усмотрению или в ответ на то, что что-то в вашей среде пошло не так (например, отключили питание).

Это значит, что каждая команда рабочего процесса должна быть, по сути, изолированной. Она не должна «знать» о том, что сделано другими командами. Нет никаких встроенных средств сохранения состояния между командами. Значит, вы не можете присвоить переменной значение, содержащее вывод одной команды, а затем передать эту переменную как входные данные другой команды. Это просто не будет работать. Кроме того, вы не можете загружать модули, содержащие дополнительные команды. Ведь у вас нет среды для хранения состояния, в которую было бы можно загрузить модуль.

В рабочие процессы включают специальные блоки InlineScript{}, который теперь станут вашими лучшими друзьями. Каждый InlineScript, по сути, выполняется как отдельная операция. Windows Workflow Foundation (WWF) запускает копию Windows PowerShell, передает ей весь InlineScript, и выполняет его. Содержимое InlineScript ведет себя как обычный сценарий Windows PowerShell.

Кроме того, бывают неявные InlineScript. WWF не может выполнять команды Windows PowerShell вне InlineScript. Когда вы используете командлет Windows PowerShell в своем рабочем процессе, Windows PowerShell смотрит, имеется ли в WWF встроенный эквивалент для него и указывает, что надо выполнить этот эквивалент вместо командлета.

Группа разработки Windows PowerShell написала WWF-эквиваленты для многих «родных» команд Windows PowerShell, но когда вы попытаетесь воспользоваться командлетом, у которого нет встроенной в WWF версии, Windows PowerShell неявно обернет вашу команду блоком InlineScript. В результате WWF запустит Windows PowerShell, выполнит вашу команду, а затем закроет экземпляр Windows PowerShell.

Благодаря отсутствию сохранения состояния между командами Windows PowerShell Workflow поддерживает возобновление работы сценариев. Также оно играет существенную роль в том, что Windows PowerShell Workflow позволяет распараллеливать выполнение команд в рамках сценария. Сценарии превращаются в многопоточные машины автоматизации. Однако отсутствие сохранения состояния вносит существенное отличие по сравнению с тем, как работают обычные сценарии и функции Windows PowerShell. Из-за него приходится тратить много сил на дополнительное планирование, необходимое для обеспечения корректного выполнения сценариев.

Если вы увидите рабочие процессы, состоящие из нескольких блоков InlineScript, это не будет чем-то необычным. Также нет ничего необычного в рабочем процессе, который не более, чем один большой блок InlineScript.

Такие рабочие процессы обеспечивают ограниченную поддержку распараллеливания и возобновления выполнения (или вовсе не обеспечивают). InlineScript —  это одна элементарная операция. Вы можете просто выполнять такие сценарии как обычные функции, используя Remoting вместо рабочих процессов. В таких случаях Windows PowerShell Workflow обеспечит очень мало реальных преимуществ.

Обеспечьте себе комфорт

Итак, одна из особенностей Windows PowerShell Workflow, бросающихся в глаза, — отсутствие сохранения данных рабочего процесса между командами. Это может оказаться полезным в целом ряде ситуаций. Если рабочий процесс прерывает и возобновляет выполнение, команды без труда могут воссоздать информацию о состоянии, такую как IP-адреса, имена компьютеров, имена пользователей и т.д. и продолжить работу.

Учитывая это встроенное ограничение, вы, пожалуй, захотите кое-что сделать для своего удобства. Установите экземпляр SQL Server (хотя бы бесплатной редакции Express) и создайте таблицы базы данных, в которых ваши рабочие процессы смогут сохранять данные. Рабочий процесс должен будет каким-либо образом уникально идентифицировать себя, например, по имени рабочего процесса и по имени компьютера, являющегося адресатом каждого экземпляра рабочего процесса.

Тогда можно будет сконструировать рабочий процесс из нескольких отдельных блоков InlineScript.  Каждый из них будет читать текущее состояние из базы данных, выполнять некоторую операцию и при необходимости обновлять базу данных новой информацией. Windows PowerShell Workflow, к своему стыду, не автоматизирует это. Наверное, здесь помогла бы архитектура, использующая синтаксис типа "$рабочий_процесс:переменная", за которым скрывается обращение к XML-файлам или SQL Server, но ее реализацию, наверно, оставили на будущее.

Хорошая новость — то, что довольно просто реализовать свой собственный механизм сохранения состояния средствами SQL Server. SQL Server лучше, чем XML-файлы, поскольку обеспечивает большую масштабируемость, к нему проще обращаться из разных мест сети и он лучше справляется с параллельным доступом из нескольких экземпляров.

Класс Microsoft .NET Framework System.Data.Sql.SqlClient несложен в использовании. Примеры можно найти в моей электронной книге «Learn PowerShell Toolmaking in a Month of Lunches». В ней я и соавтор, по сути, разработали целый модуль, который можно бесплатно скачать вместе с примерами сценариев к книге и переориентировать на свои нужды.

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

Дон Джонс (Don Jones) — лауреат премии Windows PowerShell MVP Award и пишущий редактор TechNet Magazine. Соавтор четырех книг по Windows PowerShell версии 3, среди которых бесплатные книги о создании HTML-отчетов в Windows PowerShell и Windows PowerShell Remoting. Их все можно найти на сайте PowerShellBooks.com, также можно задать Дону вопросы в форумах на сайте PowerShell.org.