Основные понятия рабочего процесса Windows PowerShell

Важно!

Поддержка этой версии Service Management Automation (SMA) завершена. Рекомендуется выполнить обновление до SMA 2022.

Один тип runbook для Service Management Automation основан на рабочих процессах Windows PowerShell. В этой статье представлен краткий обзор критически важных функций рабочих процессов, которые являются общими для модулей Runbook службы автоматизации. Дополнительные сведения о рабочих процессах см. в статье Общие сведения о рабочем процессе Windows PowerShell.

Структура runbook идентична для Service Management Automation и службы автоматизации Microsoft Azure, хотя такие последовательности обычно работают с разными ресурсами.

Рабочие процессы Windows PowerShell

Рабочий процесс — это последовательность связанных программируемых операций, в ходе которых выполняются длительные задачи или скоординированные действия на нескольких устройствах или управляемых узлах. Преимущества рабочего процесса в сравнении с использованием обычного скрипта заключаются в возможности одновременного выполнения действия по отношению ко многим устройствам и в возможности автоматического восстановления при сбоях. Рабочий процесс Windows PowerShell представляет собой сценарий Windows PowerShell, использующий Windows Workflow Foundation. Хотя рабочий процесс написан с помощью синтаксиса Windows PowerShell и запускается Windows PowerShell, он обрабатывается Windows Workflow Foundation.

Основная структура

Рабочий процесс Windows PowerShell начинается с ключевого слова Workflow, за которым следует тело скрипта, заключенное в скобки. Имя рабочего процесса следует за ключевым словом Workflow , как это показано в следующем синтаксисе. Имя рабочего процесса совпадает с именем runbook службы автоматизации.

Workflow Test-Runbook
{
   <Commands>
}

Чтобы добавить параметры в рабочий процесс, используйте ключевое слово Param, как показано в следующем примере синтаксиса. Портал управления предложит пользователю предоставить значения этих параметров при запуске модуля runbook. В этом примере используется необязательный атрибут Parameter, который указывает, является ли параметр обязательным.

Workflow Test-Runbook
{
  Param
  (
   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>,

   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>
  )
  <Commands>
}

Именование

Имя рабочего процесса должно соответствовать формату "глагол-существительное", принятому в Windows PowerShell. Список утвержденных глаголов для использования можно найти в статье Approved Verbs for Windows PowerShell Commands (Утвержденные глаголы для команд Windows PowerShell) . Имя рабочего процесса должно соответствовать имени модуля Runbook в службе автоматизации. При импорте модуля Runbook имя файла должно соответствовать имени рабочего процесса и должно заканчиваться на .ps1.

Ограничения

Полный список ограничений и различий синтаксиса между Windows PowerShell и рабочими процессами Windows PowerShell см. в разделе Различия синтаксиса между сценариями и рабочими процессами сценариев.

Действия

Действие — это конкретная задача в рабочем процессе. Так же как скрипт состоит из одной или нескольких команд, рабочий процесс состоит из одного или нескольких действий, которые выполняются в последовательности. Рабочий процесс Windows PowerShell автоматически преобразует множество командлетов Windows PowerShell в действия при выполнении рабочего процесса. Если указать один из этих командлетов в модуле Runbook, соответствующее действие фактически запускается в Windows Workflow Foundation. Для командлетов без соответствующего действия Windows PowerShell рабочий процесс автоматически запускает командлет в действии InlineScript. Существует набор командлетов, которые исключаются и не могут использоваться в рабочем процессе, если их явно не включить в блок InlineScript . Дополнительные сведения об этих понятиях см. в разделе Использование действий в рабочих процессах скриптов.

Действия рабочих процессов совместно используют набор общих параметров для настройки их работы. Сведения об общих параметрах рабочего процесса см. в статье about_WorkflowCommonParameters.

Модули интеграции

Модуль интеграции — это пакет, который содержит модуль Windows PowerShell и может быть импортирован в службу автоматизации. Модули Windows PowerShell содержат командлеты, которые можно использовать в последовательностях runbook службы автоматизации. Продукты и службы, такие как Operations Manager и Azure, обладают модулями, содержащими командлеты для их работы.

Модули интеграции, импортированные в службу автоматизации, автоматически доступны для всех runbook. Так как служба автоматизации основана на Windows PowerShell 4.0, она поддерживает автоматическую загрузку модулей. Это означает, что командлеты из установленных модулей можно использовать без их импорта в скрипт с помощью Import-Module.

Любой модуль Windows PowerShell можно импортировать в службу автоматизации при условии, что все его зависимости размещаются в одной папке. Если модуль зависит от параметров реестра или файлов, которые не находятся в пути по умолчанию, его можно импортировать, но, скорее всего, он не будет работать, так как служба автоматизации не сможет найти свои зависимости. Модули с внешними зависимостями могут быть использованы в модулях runbook путем установи их на другой узел и доступа к ним из блока сценария InlineScript .

В Service Management Automation можно использовать модули с внешними зависимостями, установив их на каждый сервер рабочей роли. Хотя командлеты в этих модулях можно использовать в модулях Runbook, они не будут обнаружены службой автоматизации для поддержки таких функций, как мастер вставки действий. Чтобы использовать этот компонент, можно создать переносимый модуль, используя командлет New-SmaPortableModule . Этот командлет создает модуль, включающий заглушку для каждого из его командлетов, который можно импортировать в службу автоматизации. Когда модуль Runbook использует один из этих командлетов, заглушка перенаправляет вызов в фактический командлет внешнего модуля. Этот модуль необходимо установить на каждом сервере Worker, в противном случае произойдет сбой вызова.

Параллельное выполнение

Одним из преимуществ рабочих процессов Windows PowerShell является возможность выполнять набор команд параллельно, а не последовательно, как это делается в стандартном скрипте. Это особенно полезно в модулях Runbook, так как они могут выполнять несколько действий, требующих значительного времени. Например, модуль Runbook может выполнять подготовку группы виртуальных машин. Вместо того чтобы выполнять каждый процесс подготовки в последовательности друг с другом, действия можно выполнять одновременно, повышая общую эффективность. Модуль Runbook продолжит работу только после выполнения всех действий.

Можно использовать ключевое слово Parallel , чтобы создать блок скрипта с несколькими командами, которые будут выполняться параллельно. Для этого используется приведенный ниже синтаксис. В этом случае действия Activity1 и Activity2 будут запущены одновременно. Действие Activity3 запустится только после завершения действий Activity1 и Activity2.

Parallel
{
  <Activity1>
  <Activity2>
}
<Activity3>

Можно использовать конструкцию ForEach -Parallel для обработки команд для каждого элемента в коллекции одновременно. Элементы в коллекции обрабатываются параллельно, а команды в блоке скрипта выполняются последовательно. Для этого используется приведенный ниже синтаксис. В этом случае Действие 1 запускается одновременно для всех элементов в коллекции. Для каждого элемента действие Activity2 будет запускаться после завершения действия Activity1. Действие 3 запускается только после завершения действий Activity1 и Activity2 для всех элементов.

ForEach -Parallel ($<item> in $<collection>)
{
  <Activity1>
  <Activity2>
}
<Activity3>

Ключевое слово Sequence используется для последовательного выполнения команд внутри блока скрипта Parallel. Блок скрипта Sequence выполняется параллельно с другими командами, однако команды в блоке выполняются последовательно. Для этого используется приведенный ниже синтаксис. В этом случае действия Activity1, Activity2 и Activity3 будут запущены одновременно. Действие Activity4 будет запускаться только после завершения действия Activity3. Действие 5 начнется после завершения всех остальных действий

Parallel
{
  <Activity1>
  <Activity2>

  Sequence
  {
   <Activity3>
   <Activity4>
  }
}
<Activity5>

Контрольные точки

Контрольная точка представляет собой моментальный снимок текущего рабочего процесса, который включает текущие значения переменных и любые выходные данные, созданные для этой точки. Последняя контрольная точка для выполнения в runbook сохраняется в базе данных службы автоматизации, чтобы рабочий процесс можно было возобновить на случай сбоя. Данные контрольной точки удаляются после завершения задания модуля Runbook.

Можно установить контрольную точку для рабочего процесса при помощи действия Checkpoint-Workflow . При включении этого действия в модуль Runbook немедленно создается контрольная точка. Если модуль Runbook приостанавливается из-за ошибки, при возобновлении задания оно возобновляется с момента последней заданной контрольной точки.

В следующем примере кода после действия Activity2 возникает ошибка, из-за чего runbook приостанавливается. При возобновлении задания оно начинается с запуска Activity2, поскольку это действие было сразу после последней заданной контрольной точки.

<Activity1>
Checkpoint-Workflow
<Activity2>
<Error>
<Activity3>

Контрольные точки следует задавать в runbook после действий, которые могут быть подвержены ошибкам и не должны повторяться при возобновлении работы модуля Runbook. Например, модуль Runbook может создавать виртуальную машину. Контрольную точку следует создавать как до, так и после команды создания виртуальной машины. В случае сбоя создания команды повторяются, когда возобновляется выполнение модуля Runbook. Если создание выполнено успешно, но runbook позже завершается сбоем, виртуальная машина не будет создана повторно при возобновлении работы модуля Runbook.

Дополнительные сведения о контрольных точках см. в статье Добавление контрольных точек в рабочий процесс сценария.

Приостановка runbook

Вы можете настроить принудительную остановку работы runbook с помощью действия Suspend-Workflow. Это действие задает контрольную точку и вызывает немедленную приостановку рабочего процесса. Приостановка рабочих процессов полезна для модулей runbook, в которых может потребоваться выполнение определенных задач вручную перед запуском следующего набора действий.

Дополнительные сведения о приостановке рабочего процесса см. в статье Making a Workflow Suspend Itself (Настройка приостановки рабочего процесса).

InlineScript (Встроенный сценарий)

Действие InlineScript запускает блок команд в отдельном сеансе, не в рамках рабочего процесса, и возвращает выходные данные в рабочий процесс. Пока команды в рабочем процессе отправляются в Windows Workflow Foundation для обработки, команды в блоке InlineScript обрабатываются при помощи Windows PowerShell. Действие использует стандартные общие параметры рабочего процесса, включая PSComputerName и PSCredential, которые позволяют указать, что блок кода будет выполняться на другом компьютере или использовать альтернативные учетные данные.

InlineScript использует описанный ниже синтаксис.

InlineScript
{
  <Script Block>
} <Common Parameters>

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

Чтобы запустить блок кода на другом компьютере, с действием InlineScript используются параметры PSComputer и PSCredential. Для предоставления значений для этих параметров в модуле runbook обычно используется глобальный ресурс, например Credential или Connection . Приведенный ниже пример кода демонстрирует запуск набора команд на компьютере, представленном подключением MyConnection.

$con = Get-AutomationConnection -Name 'MyConnection'
$securepassword = ConvertTo-SecureString -AsPlainText -String $con.Password -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $con.Username, $securepassword
InlineScript
{
  <Commands>
} -PSComputer $con.ComputerName -PSCredential $cred

Хотя действия InlineScript могут быть важными в некоторых runbook, их следует использовать только при необходимости, учитывая следующие основания:

• Вы не можете использовать контрольные точки из блока InlineScript . Если в блоке происходит сбой, необходимо восстановить его выполнение с начала.

• InlineScript влияет на масштабируемость runbook, поскольку содержит сеанс Windows PowerShell на всю длину блока InlineScript.

• Такие действия, как Get-AutomationVariable и Get-AutomationPSCredential , недоступны в блоке InlineScript.

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

• Можно задать контрольную точку рабочего процесса после каждой итерации. Если задание приостановлено или прервано, а затем возобновлено, цикл также будет возобновлен.

• Для параллельной обработки элементов коллекции можно использовать параметр ForEach "Parallel.

Соблюдайте следующие рекомендации при использовании InlineScript в runbook:

• Можно передать значения в сценарий, используя модификатор области $Using . Например, переменная $abc, заданная вне InlineScript, превратится в $using:abc внутри InlineScript.

• Для получения выходных данных из InlineScriptприсвойте выходные данные переменной и выводите все возвращаемые данные в выходной поток. В следующем примере строка hi назначается переменной с именем $output.

  $output = InlineScript { Write-Output "hi" }
  

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

Дополнительные сведения об использовании InlineScript см. в статье Выполнение команд Windows PowerShell в рабочем процессе и about_InlineScript.

Дальнейшие действия

• Создание модулей Runbook службы автоматизации.