Поделиться через

  • Статья

Основные понятия Runbook

 

Опубликовано: Июнь 2016

Применимо к:Windows Azure Pack for Windows Server, System Center 2012 R2 Orchestrator

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

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

Рабочие процессы 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 явным образом. Дополнительные сведения об этих понятиях см. в статье Using Activities in Script Workflows (Использование действий в рабочих процессах сценария).

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

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

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

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

Любой модуль Windows PowerShell можно импортировать в Автоматизация, при условии что все его зависимости размещаются в одной папке. Если этот модуль зависит от параметров реестра или файлов, которые не находятся по стандартному пути, его можно импортировать, однако, скорее всего, он не будет работать, так как Автоматизация, не сможет найти его зависимости. Модули с внешними зависимостями могут быть использованы в модулях runbook путем установи их на другой узел и доступа к ним из блока сценария a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_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. Элементы в коллекции обрабатываются параллельно, тогда как команды в блоке сценария выполняются последовательно. При этом используется приведенный ниже синтаксис. В этом случае действие Activity1 будет запущено одновременно со всеми элементами в коллекции. Для каждого элемента действие Activity2 будет запускаться после завершения действия Activity1. Действие Activity3 запустится только после завершения действий Activity1 и Activity2 для всех элементов.

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

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

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.

Дополнительные сведения о контрольных точках см. в статье Adding Checkpoints to a Script Workflow (Добавление контрольных точек в рабочий процесс сценария).

Приостановка модуля 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 и InlineScript. Для предоставления значений для этих параметров в модуле runbook обычно используется глобальный ресурс, например a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_Credentials или a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_Connections. Приведенный ниже пример кода демонстрирует запуск набора команд на компьютере, представленном подключением 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.