Основные понятия рабочего процесса Windows PowerShell
Один из типов runbook для службы автоматизации управления службами основан на рабочих процессах Windows PowerShell. В этой статье представлен краткий обзор критически важных функций рабочих процессов, которые являются общими для модулей Runbook службы автоматизации. Дополнительные сведения о рабочих процессах см. в статье Общие сведения о рабочем процессе Windows PowerShell.
Структура runbook идентична модулям Runbook для службы автоматизации управления службами и microsoft служба автоматизации Azure хотя они обычно работают с разными ресурсами.
Рабочие процессы Windows PowerShell
Рабочий процесс — это последовательность связанных программируемых операций, в ходе которых выполняются длительные задачи или скоординированные действия на нескольких устройствах или управляемых узлах. Преимущества рабочего процесса в сравнении с использованием обычного скрипта заключаются в возможности одновременного выполнения действия по отношению ко многим устройствам и в возможности автоматического восстановления при сбоях. Рабочий процесс Windows PowerShell представляет собой сценарий Windows PowerShell, использующий Windows Workflow Foundation. Хотя рабочий процесс записывается с помощью синтаксиса Windows PowerShell и запускается Windows PowerShell, он обрабатывается Windows Workflow Foundation.
Основная структура
Рабочий процесс Windows PowerShell начинается с ключевого слова рабочего процесса , за которым следует текст скрипта, заключенного в фигурные скобки. Имя рабочего процесса следует за ключевым словом Workflow , как это показано в следующем синтаксисе. Имя рабочего процесса соответствует имени модуля Runbook службы автоматизации.
Workflow Test-Runbook
{
<Commands>
}
Чтобы добавить параметры в рабочий процесс, используйте ключевое слово Param , как показано в следующем синтаксисе. Портал управления предложит пользователю предоставить значения этих параметров при запуске модуля runbook. В этом примере используется необязательный атрибут параметра, указывающий, является ли параметр обязательным.
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 .
С помощью службы автоматизации управления службами можно использовать модули с внешними зависимостями, установив их на каждом рабочем сервере. Хотя командлеты в этих модулях можно использовать в модулях 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 используется для выполнения команд в последовательности в блоке параллельных скриптов. Блок скрипта последовательности выполняется параллельно с другими командами, но команды в блоке выполняются последовательно. Для этого используется приведенный ниже синтаксис. В этом случае действия Activity1, Activity2 и Activity3 будут запущены одновременно. Действие Activity4 будет запускаться только после завершения действия Activity3. Действие 5 начнется после завершения всех остальных действий.
Parallel
{
<Activity1>
<Activity2>
Sequence
{
<Activity3>
<Activity4>
}
}
<Activity5>
Контрольные точки
Контрольная точка представляет собой моментальный снимок текущего состояния рабочего процесса, который включает текущие значения переменных и любые выходные данные, созданные для этой точки. Последняя контрольная точка, выполненная в runbook, сохраняется в базе данных службы автоматизации, чтобы рабочий процесс смог возобновиться даже в случае сбоя. Данные контрольной точки удаляются после завершения задания модуля Runbook.
Можно установить контрольную точку для рабочего процесса при помощи действия Checkpoint-Workflow . При включении этого действия в модуль Runbook немедленно создается контрольная точка. Если модуль Runbook приостанавливается из-за ошибки, при возобновлении задания оно возобновляется с момента последней заданной контрольной точки.
В следующем примере кода ошибка возникает после действия 2, что приводит к приостановке модуля 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 не установлены в службе автоматизации или если действие имеет только разрешения для локального выполнения на целевом компьютере. Следующая диаграмма иллюстрирует эту схему.
Чтобы запустить блок кода на другом компьютере, параметры PSComputer и PSCredential используются с действием InlineScript . Для предоставления значений для этих параметров в модуле 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 можно использовать для параллельного обработки элементов коллекции.
Если вы используете InlineScript в runbook, помните следующие рекомендации.
Можно передать значения в сценарий, используя модификатор области $Using . Например, переменная с именем $abc, которая была задана за пределами InlineScript, станет $using:abc внутри InlineScript.
Чтобы вернуть выходные данные из InlineScript, назначьте выходные данные переменной и выведите все данные, которые будут возвращены в выходной поток. В следующем примере строка будет назначена переменной с именем $output.
$output = InlineScript { Write-Output "hi" }Избегайте определения рабочих процессов в области InlineScript . Несмотря на то, что некоторые рабочие процессы могут работать правильно, это не тестируемый сценарий. Из-за этого возможны путаные сообщения об ошибках или непредвиденное поведение.
Дополнительные сведения об использовании InlineScript см. в статье о выполнении команд Windows PowerShell в рабочем процессе и about_InlineScript.
Следующие шаги
- Создание модулей Runbook службы автоматизации.