Windows PowerShell ワークフローの概念

[アーティクル]
11/01/2024

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

Runbook の構造は、Service Management Automation と Microsoft Azure Automation の Runbook の間で同じですが 2 つは通常、異なるリソースで動作します。

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

アクティビティ

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

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

統合モジュール

Integration Module は、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 が完了した後に開始されます。 Activity5 は、他のすべてのアクティビティが完了した後に開始されます

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 によって処理されます。このアクティビティでは、 PSComputerName や PSCredential など、標準のワークフロー共通パラメーターを使用します。これにより、別のコンピューターまたは代替資格情報を使用してコードブロックを実行するように指定できます。

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

InlineScript
{
  <Script Block>
} <Common Parameters>

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

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

別のコンピューターでコードブロックを実行するために、 PSComputer パラメーターと PSCredential パラメーターが InlineScript アクティビティと共に使用されます。一般的に、このようなパラメーターの値を指定するには、 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 は、InlineScript ブロック全体の Windows PowerShell セッションを保持するため、Runbook のスケーラビリティに影響します。
Get-AutomationVariable や Get-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 の使用の詳細については、「ワークフローでの Windows PowerShell コマンドの実行とabout_InlineScript」を参照してください。

次のステップ

Automation Runbook を作成する。

次の方法で共有