Windows PowerShell ワークフローの概念

重要

このバージョンの Service Management Automation (SMA) はサポート終了に達しました。 SMA 2022 にアップグレードすることをお勧めします。

Service Management Automation の Runbook の 1 つの種類は Windows PowerShell ワークフローに基づいています。 この記事では、Automation Runbook に共通するワークフローの重要な機能の概要について簡単に説明します。 ワークフローの詳細については、「 Windows PowerShell ワークフローについて」をご覧ください。

Runbook の構造は、Service Management Automation と Microsoft Azure Automation の Runbook で同じですが、両者は通常、異なるリソースを使用します。

Windows PowerShell のワークフロー

A workflow is a sequence of programmed, connected steps that perform long-running tasks or require the coordination of multiple steps across multiple devices or managed nodes. ワークフローが通常のスクリプトよりも優れている点としては、同時に複数のデバイスに対して操作を実行できることや、障害から自動的に復元できることなどがあります。 Windows PowerShell ワークフローは、Windows Workflow Foundation を使用した Windows PowerShell スクリプトです。 ワークフローはWindows PowerShell構文で記述され、Windows PowerShellによって起動されますが、Windows Workflow Foundation によって処理されます。

基本構造

Windows PowerShell ワークフローは、Workflow キーワードから始まり、波かっこで囲まれたスクリプトの本文が続きます。 次の構文に示されているように、ワークフロー名が Workflow キーワードに続きます。 ワークフロー名は、Automation 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 で標準の Verb-Noun 形式に従って付けます。 使用が承認されている動詞の一覧については、「 Approved Verbs for Windows PowerShell Commands (Windows PowerShell コマンドで承認されている動詞) 」をご覧ください。 ワークフローの名前は、Automation の Runbook の名前と一致する必要があります。 Runbook がインポートされている場合、ファイル名はワークフロー名と一致していなければならず、末尾は .ps1 でなければなりません。

制限事項

Windows PowerShell ワークフローと Windows PowerShell の制限事項と構文の違いの完全な一覧については、 スクリプト ワークフローとスクリプトの構文に関する相違点についての記事をご覧ください。

Activities

アクティビティとは、ワークフロー内の特定のタスクです。 スクリプトが 1 つ以上のコマンドで構成されているのと同様に、ワークフローも順番に実行される 1 つ以上のアクティビティで構成されます。 Windows PowerShell ワークフローでは、ワークフローの実行時に Windows PowerShell コマンドレットの多くが自動でアクティビティに変換されます。 Runbook でこれらのコマンドレットのいずれかを指定すると、対応するアクティビティは、実際には Windows Workflow Foundation で実行されます。 対応するアクティビティがないコマンドレットの場合、Windows PowerShell Workflow は InlineScript アクティビティ内でコマンドレットを自動的に実行します。 InlineScript ブロックに明示的に含めない限り、除外され、ワークフローで使用できないコマンドレットのセットがあります。 これらの概念の詳細については、「 スクリプト ワークフローでのアクティビティの使用」を参照してください。

ワークフロー アクティビティは、操作を構成するための一連の共通パラメーターを共有します。 ワークフローの共通パラメーターの詳細については、「about_WorkflowCommonParameters」を参照してください。

統合モジュール

"統合モジュール" は、Windows PowerShell モジュールを含み、Automation にインポートできるパッケージです。 Windows PowerShell モジュールには、Automation Runbook で使用できるコマンドレットが含まれています。 Operations Manager や Azure などの製品とサービスには、その操作に固有のコマンドレットが含まれるモジュールがあります。

Automation にインポートされた統合モジュールは自動的にすべての Runbook で使用できるようになります。 Automation は Windows PowerShell 4.0 に基づいているため、モジュールの自動読み込みをサポートしています。つまり、インストールされているモジュールのコマンドレットは、Import-Module を使用してスクリプトにインポートしなくても使用できます。

すべての依存関係を 1 つのフォルダー内に配置できる限り、すべての Windows PowerShell モジュールを Automation にインポートできます。 モジュールがレジストリ設定または既定のパスにないファイルに依存している場合は、インポートできますが、Automation では依存関係を見つけることができないため、ほとんどの場合は機能しません。 外部依存関係を持つモジュールを Runbook 内で使用するには、別のホストにインストールし、 InlineScript スクリプト ブロックを使用してアクセスします。

Service Management Automation と共に外部依存関係を持つモジュールを使用するには、モジュールを各 Worker サーバーにインストールします。 これらのモジュールのコマンドレットは Runbook で使用できますが、アクティビティの挿入ウィザードなどの機能をサポートするために Automation では検出されません。 この機能を使用するには、 New-SmaPortableModule コマンドレットを使用してポータブル モジュールを作成できます。 このコマンドレットでは、各コマンドレットのスタブを含み、Automation にインポートできるモジュールが作成されます。 Runbook がこのようなコマンドレットのいずれかを使用すると、スタブはその呼び出しを外部モジュールの実際のコマンドレットにリダイレクトします。 このモジュールは、各 Worker サーバーにインストールする必要があります。そうしないと、失敗します。

並列実行

Windows PowerShell ワークフローの利点の 1 つは、一般的なスクリプトのように順番に実行するのでなく、一連のコマンドを並行して実行できることです。 複数の操作を実行すると、完了までに時間がかかる可能性があるので、Runbook では特に役立ちます。 たとえば、Runbook は仮想マシンのセットをプロビジョニングすることがあります。 各プロビジョニング プロセスを順番に実行するのではなく、アクションを同時に実行できるため、全体的な効率が向上します。 すべてが完了したときにのみ、Runbook が続行します。

Parallel キーワードを使用して、同時に実行される複数のコマンドを含むスクリプト ブロックを作成できます。 これには、次に示す構文を使用します。 この場合、Activity1 と Activity2 は同時に開始されます。 Activity3 は、Activity1 と Activity2 の両方が完了した後にのみ開始されます。

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

ForEach -Parallel の構文を使用することにより、コレクション内の各項目のコマンドを同時に処理できます。 コレクション内の項目は並行して処理され、スクリプト ブロック内のコマンドは順番に実行されます。 これには、次に示す構文を使用します。 この場合、Activity1 はコレクション内のすべての項目に対して同時に開始されます。 各項目について、Activity1 が完了してから Activity2 が開始されます。 Activity3 は、すべてのアイテムに対して 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 内で最後に作成されたチェックポイントは、障害が発生した場合でもワークフローを再開できるように、Automation データベースに保存されます。 Runbook ジョブが完了すると、チェックポイント データは削除されます。

Checkpoint-Workflow アクティビティを使用してワークフローにチェックポイントを設定できます。 この活動を Runbook に含めると、直ちにチェックポイントが作成されます。 Runbook がエラーで一時停止すると、ジョブを再開したときに、最後に設定されたチェックポイントのポイントから再開されます。

次のサンプル コードでは、Activity2 の後にエラーが発生し、Runbook が中断されます。 ジョブを再開すると、Activity2 は最後にチェックポイントが設定された直後であるため、Activity2 が開始されます。

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

Runbook のチェックポイントは、エラーが発生しやすく、Runbook が再開されても繰り返されないアクティビティの後に設定する必要があります。 たとえば、仮想マシンを作成する Runbook があるとします。 チェックポイントをコマンドの前後に設定して、仮想マシンを作成できます。 作成に失敗すると、Runbook の再開時に作成のコマンドが繰り返されます。 作成が成功しても Runbook が後で失敗した場合、Runbook が再開されても仮想マシンは再度作成されません。

チェックポイントの詳細については、「スクリプト ワークフローへのチェックポイントの追加」を参照してください。

Runbook を中断する

Suspend-Workflow 活動を使用して、Runbook を強制的に一時停止することができます。 この活動はチェックポイントを設定し、ワークフローを直ちに一時停止します。 ワークフローの一時停止は、別の活動セットを実行する前に手動の手順を実行する必要がある Runbook などに役立ちます。

ワークフローの一時停止の詳細については、「 Making a Workflow Suspend Itself (ワークフローの一時停止)」をご覧ください。

InlineScript

InlineScript 活動により、ワークフローではない別のセッション内でコマンドのブロックが実行され、出力がワークフローに返されます。 ワークフロー内のコマンドは Windows Workflow Foundation に送信されて処理されますが、InlineScript ブロック内のコマンドは Windows PowerShell によって処理されます。 アクティビティでは、 PSComputerNamePSCredential などの標準ワークフロー共通パラメーターを使用します。これにより、コード ブロックを別のコンピューターで実行するか、代替資格情報を使用するように指定できます。

InlineScript は、次に示す構文を使用します。

InlineScript
{
  <Script Block>
} <Common Parameters>

Runbook 内で InlineScript を使用する最も一般的な例は、別のコンピューター上でコードのブロックを実行することです。 これは、Runbook のコマンドレットが Automation にインストールされていない場合、またはアクションがターゲット コンピューター上でローカルに実行されるアクセス許可のみを持っている場合に必要です。 次の図をご覧ください。

インライン スクリプト図。

別のコンピューター上でコード ブロックを実行するには、PSComputer および PSCredential パラメーターを InlineScript 活動に使用します。 一般的に、このようなパラメーターの値を指定するには、 CredentialConnection などのグローバル リソースが使用されます。 次のサンプル コードは、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 ブロックの長さ全体にわたって Windows PowerShell セッションが保持されるため、InlineScript は Runbook の拡張性に影響を与えます。

  • Get-AutomationVariableGet-AutomationPSCredential などのアクティビティは、InlineScript ブロックでは使用できません。

InlineScript を使用する必要がある場合は、スコープを最小限に抑える必要があります。 たとえば、コレクションに対して Runbook を繰り返し、同じ操作を各項目に適用する場合、InlineScript の外部でループを実行する必要があります。 この方法には次の利点があります。

  • 各繰り返し処理の後で、ワークフローの チェックポイント を作成できます。 ジョブが一時停止されるか中断され、再開されると、ループを再開することができます。

  • ForEach "Parallel を使用して、コレクション項目を並列処理できます。

Runbook で InlineScript を使用する場合は、次の推奨事項に留意してください。

  • 値をスクリプトに渡すには、 $Using スコープ修飾子を使用します。 たとえば、InlineScript の外部で設定された $abc という変数は、InlineScript 内では $using:abc になります。

  • InlineScript から出力を返すには、出力を変数に割り当て、出力ストリームに返すデータを出力します。 次の例では、文字列 hi を $output という変数に割り当てます。

    $output = InlineScript { Write-Output "hi" }
    
  • InlineScript スコープ内にワークフローを定義しないようにします。 一部のワークフローが正しく動作しているように見えるかもしれませんが、これはテスト済みのシナリオではありません。 そのため、混乱を招くエラー メッセージや予期しない動作が発生する可能性があります。

InlineScript の使用の詳細については、「ワークフローとabout_InlineScriptでのWindows PowerShell コマンドの実行」を参照してください。

次の手順