Azure Automation での Runbook の実行
Azure Automation でのプロセス自動化によって、PowerShell、PowerShell ワークフロー、グラフィカル Runbook を作成し、管理することができます。 詳細については、Azure Automation Runbook に関するページを参照してください。
Runbook は、Automation によって、その内部で定義されているロジックに基づいて実行されます。 Runbook は、中断された場合、先頭から再開されます。 この動作では、一時的な問題が発生した場合の再起動をサポートするように Runbook を作成する必要があります。
Azure Automation で Runbook を開始すると、ジョブが作成されます。ジョブは Runbook の単一の実行インスタンスです。 ジョブごとに、Azure サブスクリプションに接続することによって Azure リソースにアクセスします。 ジョブでデータ センター内のリソースにアクセスできるのは、それらのリソースがパブリック クラウドからアクセスできる場合に限られます。
Azure Automation では、Runbook の実行中に各ジョブを実行するための worker が割り当てられます。 worker は多数の Automation アカウントで共有されますが、異なる Automation アカウントからのジョブは互いに分離されます。 どの worker がジョブの要求を処理するかを制御することはできません。
Azure portal で Runbook の一覧を表示すると、各 Runbook に対して開始された各ジョブの状態が示されます。 Azure Automation には、ジョブのログが最大 30 日間保存されます。
次の図では、PowerShell Runbook、PowerShell ワークフロー Runbook、グラフィック Runbookでの Runbook ジョブのライフサイクルを示します。
Note
個人データの表示または削除については、特定の領域およびニーズに応じて、GDPR の一般的なデータ主体の要求、GDPR の Azure データ主体要求、または GDPR の Windows データ主体の要求のそれぞれに関するページを参照してください。 GDPR の詳細については、Microsoft Trust Center の GDPR に関するセクションおよび Service Trust Portal の GDPR に関するセクションをご覧ください。
Runbook の実行環境
Azure Automation の Runbook は、Azure サンドボックスまたは Hybrid Runbook Worker のいずれかで実行できます。
Azure のリソースに対して認証および実行されるように設計されている場合、Runbook は Azure サンドボックスで実行されます。 Azure Automation によって、サンドボックスでの Runbook の実行中に各ジョブを実行する worker が割り当てられます。 worker は多数の Automation アカウントで共有されますが、異なる Automation アカウントからのジョブは互いに分離されます。 同じサンドボックスを使用するジョブは、サンドボックスのリソース制限に縛られます。 Azure サンドボックス環境では、対話型操作はサポートされていません。 これにより、アウトプロセスのすべての COM サーバーにアクセスできなくなります。また、Runbook の Win32 プロバイダーに WMI 呼び出しを行うことはできません。 これらのシナリオは、Windows Hybrid Runbook Worker で Runbook を実行することによってのみサポートされます。
また、Hybrid Runbook Worker を使用すると、そのロールがホストされているコンピューターで、環境内のローカル リソースに対して Runbook を直接実行することができます。 Azure Automation によって Runbook が格納および管理された後、1 つ以上の割り当てられたコンピューターに配信されます。
Azure Storage、Azure Key Vault、または Azure SQL で Azure Firewall を有効にすると、それらのサービスの Azure Automation Runbook からのアクセスがブロックされます。 信頼される Microsoft サービスを許可するファイアウォール例外が有効になっている場合でも、Automation は信頼されるサービス一覧に含まれていないため、アクセスはブロックされます。 ファイアウォールが有効になっている場合、Hybrid Runbook Worker と 仮想ネットワーク サービス エンドポイント を使用しないとアクセスできません。
Note
- Linux Hybrid Runbook Worker 上で実行するには、スクリプトが署名されていること、またワーカーが適切に構成されていることが必要です。 または、署名の検証をオフにする必要があります。
- Runbook の実行は、サンドボックスのタイムゾーンに依存しないようにする必要があります。
次の表では、いくつかの Runbook 実行タスクと、それぞれに対して推奨される実行環境を示します。
| タスク | レコメンデーション | メモ |
|---|---|---|
| Azure リソースと統合する | Azure サンドボックス | Azure でホストされ、認証がより簡単です。 Azure VM で Hybrid Runbook Worker を使用している場合は、マネージド ID による Runbook 認証を使用できます。 |
| Azure リソースを管理するための最適なパフォーマンスを得る | Azure サンドボックス | スクリプトは同じ環境内で実行され、待ち時間が短くなります。 |
| 運用コストを最小限に抑える | Azure サンドボックス | コンピューティングのオーバーヘッドがなく、VM の必要がありません。 |
| 実行時間の長いスクリプトを実行する | Hybrid Runbook Worker | Azure サンドボックスにはリソースの制限があります。 |
| ローカル サービスと対話する | Hybrid Runbook Worker | ホスト コンピューター、他のクラウド環境内のリソース、またはオンプレミス環境内のリソースに直接アクセスします。 |
| サードパーティのソフトウェアと実行可能ファイルが必要である | Hybrid Runbook Worker | 自分でオペレーティング システムを管理し、ソフトウェアをインストールできます。 |
| Runbook でファイルまたはフォルダーを監視する | Hybrid Runbook Worker | Hybrid Runbook Worker で Watcher タスクを使用します。 |
| リソースを大量に消費するスクリプトを実行する | Hybrid Runbook Worker | Azure サンドボックスにはリソースの制限があります。 |
| 特定の要件を持つモジュールを使用する | Hybrid Runbook Worker | 次に例をいくつか示します。 WinSCP - winscp.exe に対する依存関係 IIS administration - IIS の有効化または管理に対する依存関係 |
| インストーラでモジュールをインストールする | Hybrid Runbook Worker | サンドボックス用のモジュールでは、コピーがサポートされている必要があります。 |
| 4.7.2 以外のバージョンの .NET Framework が必要な Runbook またはモジュールを使用する | Hybrid Runbook Worker | Azure サンドボックスでは .NET Framework 4.7.2 がサポートされており、別のバージョンへのアップグレードはサポートされていません。 |
| 昇格が必要なスクリプトを実行する | Hybrid Runbook Worker | サンドボックスでは、昇格は許可されません。 Hybrid Runbook Worker を使用すると、UAC をオフにして、昇格が必要なコマンドを実行するときに Invoke-Command を使用できます。 |
| Windows Management Instrumentation (WMI) へのアクセスを必要とするスクリプトを実行する | Hybrid Runbook Worker | クラウドのサンドボックスで実行されているジョブでは、WMI プロバイダーにアクセスできません。 |
サンドボックスでの一時ストレージ
Runbook ロジックの一部として一時ファイルを作成する必要がある場合は、Azure で実行されている Runbook に対して、Azure サンドボックスの Temp フォルダー (つまり $env:TEMP) を使用できます。 唯一の制限は、各サンドボックスのクォータである 1 GB を超えるディスク領域を使用できないことです。 PowerShell ワークフローを使用する場合、PowerShell ワークフローによってチェックポイントが使用され、スクリプトが別のサンドボックスで再試行される可能性があるため、このシナリオでは問題が発生する可能性があります。
ハイブリッド サンドボックスでは、Hybrid Runbook Worker でのストレージの可用性に基づいて C:\temp を使用できます。 ただし、Azure VM に関する推奨事項によって、永続化させる必要があるデータについては、Windows または Linux の一時ディスクを使用しないでください。
リソース
Runbook には必ず、リソース (VM、ネットワーク、ネットワーク上のリソースなど) を扱うロジックが含まれています。 リソースは Azure サブスクリプションに関連付けられており、どのリソースにアクセスする場合でも Runbook に適切な資格情報が必要となります。 Runbook におけるリソースの処理の例については、「リソースの処理」を参照してください。
セキュリティ
Azure Automation では Microsoft Defender for Cloud を利用してリソースを守り、Linux システムのリスクを検出します。 リソースが Azure 内にあるかどうかにかかわらず、セキュリティはワークロード全体で確保されます。 Azure Automation での認証の概要に関するページを参照してください。
VM 上でスクリプトを署名ありまたは署名なしで実行できるユーザーには、Defender for Cloud によって制約が課されます。 VM へのルート アクセスを持つユーザーは、明示的にデジタル署名を使用してマシンを構成するか、デジタル署名をオフにする必要があります。 それ以外のユーザーが、Automation アカウントを作成し、該当する機能を有効にした後で実行できるのは、オペレーティング システムの更新プログラムを適用するスクリプトだけです。
サブスクリプション
Azure サブスクリプションは、課金の対象となる 1 つまたは複数のクラウドベース サービスをご利用いただくために Microsoft との間で交わされる契約です。 Azure Automation では、各サブスクリプションが 1 つの Azure Automation アカウントに関連付けられます。また、そのアカウントには、複数のサブスクリプションを作成することができます。
資格情報
Azure のリソースであれ、サードパーティ システムのリソースであれ、Runbook がリソースにアクセスするためには、Runbook に適切な資格情報が必要となります。 これらの資格情報は、Azure Automation や Key Vault などに格納されます。
Azure Monitor
Azure Automation では、そのマシンの操作を監視するために Azure Monitor が使用されます。 これらの操作には、Log Analytics ワークスペースと Log Analytics エージェントが必要です。
Windows 用の Log Analytics エージェント
Windows 用の Log Analytics エージェントは、Azure Monitor と連携して、Windows VM と物理コンピューターを管理します。 マシンは、Azure 内で実行されていても、Azure 以外の環境 (ローカル データセンターなど) で実行されていてもかまいません。
Note
Windows 用の Log Analytics エージェントは、以前は Microsoft Monitoring Agent (MMA) と呼ばれていました。
Linux 用 Log Analytics エージェント
Linux 用 Log Analytics エージェントは、Windows 用のエージェントと同様に機能しますが、Linux コンピューターを Azure Monitor に接続します。 このエージェントは、ルート アクセス許可が必要なコマンドを実行する特定のサービス アカウントを使用してインストールされます。 詳細については、「サービス アカウント」を参照してください。
Log Analytics エージェント ログは、/var/opt/microsoft/omsagent/log/omsagent.log にあります。
Runbook のアクセス許可
Runbook には、資格情報を通じて Azure に対する認証を行うためのアクセス許可が必要です。 Azure Automation の認証の概要に関するページを参照してください。
モジュール
Azure Automation には、次の PowerShell モジュールが含まれています。
- Orchestrator.AssetManagement.Cmdlets - Azure サンドボックス環境内または Windows Hybrid Runbook Worker 上で Runbook を実行する場合にのみ利用可能ないくつかの内部コマンドレットが含まれています。 これらのコマンドレットは、Automation アカウント リソースを操作するために Azure PowerShell コマンドレットの代わりに使用するように設計されています。
- Az.Automation - AzureRM Automation モジュールを置き換える Azure Automation を操作するために推奨される PowerShell モジュールです。 Az.Automation モジュールは、Automation アカウントを作成するときに自動的に含められないため、手動でインポートする必要があります。
- AzureRM.Automation - Automation アカウントを作成するときに既定でインストールされます。
また、Runbook と DSC 構成に必要なコマンドレットに基づいて、インストール可能なモジュールもサポートされています。 Runbook と DSC 構成で使用できるモジュールの詳細については、「Azure Automation でモジュールを管理する」を参照してください。
証明書
Azure Automation では、Azure に対する認証に証明書が使用されるほか、Azure またはサードパーティのリソースに証明書が追加されます。 証明書は、Runbook や DSC の構成からアクセスできるよう安全に保存されます。
Runbook では、証明機関 (CA) による署名のない自己署名証明書を使用できます。 「新しい証明書の作成」を参照してください。
ジョブ
Azure Automation では、同じ Automation アカウントから複数のジョブを実行するための環境がサポートされています。 1 つの Runbook で、多数のジョブを同時に実行することができます。 同時に実行するジョブが多いほど、同じサンドボックスにディスパッチする頻度が上がります。 サンドボックスでは、最大 10 個のジョブを実行できます。 サンドボックス内でジョブが実行されていない場合、サンドボックスは削除されます。そのため、ファイルの保存には使用しないでください。
同じサンドボックス プロセスで実行するジョブは、お互いに影響し合う可能性があります。 1 つの例は、Disconnect-AzAccount コマンドレットの実行です。 このコマンドレットを実行すると、共有サンドボックス プロセス内の各 Runbook ジョブが切断されます。 このシナリオに取り組む例については、「コンカレント ジョブの防止」を参照してください。
Note
Azure サンドボックスで実行されている Runbook から開始された PowerShell ジョブは、完全な PowerShell 言語モードで実行されないことがあります。
ジョブの状態
次の表では、ジョブで可能性のある状態について説明します。 Azure portal で、すべての Runbook ジョブの状態の概要を表示したり、特定の Runbook ジョブの詳細にドリルダウンしたりできます。 Log Analytics ワークスペースとの統合を構成し、Runbook のジョブの状態やジョブ ストリームを転送することも可能です。 Azure Monitor ログとの統合の詳細については、「Automation から Azure Monitor ログにジョブの状態とジョブ ストリームを転送する」を参照してください。 Runbook で状態を扱う例については、「ジョブの状態を取得する」も参照してください。
| Status | 説明 |
|---|---|
| アクティブ化中 | ジョブをアクティブ化しています。 |
| 完了 | ジョブは正常に完了しました。 |
| Failed | グラフィック Runbook または PowerShell ワークフロー Runbook のコンパイルが失敗しました。 PowerShell Runbook を開始できなかったか、ジョブで例外が発生しました。 「Azure Automation の Runbook の種類」を参照してください。 |
| 失敗、リソースを待機中 | ジョブは fair share の限界に 3 回到達し、毎回、同じチェックポイントから、または Runbook の先頭から起動したために、失敗しました。 |
| キュー登録済み | ジョブは、開始できるように、Automation ワーカー上のリソースが使用可能になるのを待機しています。 |
| 再開中 | システムは、ジョブが停止された後、そのジョブを再開しています。 |
| 実行中 | ジョブは実行中です。 |
| 実行中、リソースを待機中 | ジョブはフェア シェア制限に達したためにアンロードされました。 ジョブは最後のチェックポイントからすぐに再開します。 |
| 開始中 | ジョブがワーカーに割り当てられており、システムがジョブを起動しています。 |
| Stopped | ジョブは完了した後、ユーザーによって停止されました。 |
| 停止中 | システムは、ジョブを停止しています。 |
| 中止 | グラフィック Runbook と PowerShell ワークフロー Runbook のみに適用されます。 ユーザーか、システムか、または Runbook 内のコマンドによってジョブは中断されました。 Runbook にチェックポイントがない場合は、先頭から開始されます。 チェックポイントがある場合は、最後のチェックポイントからもう一度再開できます。 システムは、例外が発生した場合にのみ Runbook を中断します。 既定で、ErrorActionPreference 変数は、エラーでもジョブの実行を継続することを示す [Continue] に設定されます。 このユーザー設定変数を [Stop] に設定すると、エラーが発生したときにジョブは中断されます。 |
| Suspending | グラフィック Runbook と PowerShell ワークフロー Runbook のみに適用されます。 ユーザーの要求を受けてシステムはジョブを中断しようとしています。 Runbook は、次のチェックポイントに到達してからでないと、中断できません。 最後のチェックポイントに既に到達している場合は、完了してからでないと中断できません。 |
| 新しい | ジョブは送信が完了したばかりで、まだアクティブ化されていません。 |
アクティビティ ログ
Azure Automation で Runbook を実行すると、その Automation アカウントのアクティビティ ログに詳細が書き込まれます。 ログの使用の詳細については、「アクティビティ ログから詳細を取得する」を参照してください。
例外
ここでは、Runbook で例外または断続的な問題を処理するいくつかの方法について説明します。 たとえば WebSocket の例外があります。 正しい例外処理を使用すると、一時的なネットワーク エラーによって Runbook が失敗することを防ぐことができます。
ErrorActionPreference
ErrorActionPreference 変数により、終了しないエラーに対して PowerShell が対応する方法が決まります。 終了するエラーは常に終了し、ErrorActionPreference の影響を受けません。
Runbook で ErrorActionPreference を使用すると、Get-ChildItem コマンドレットの PathNotFound などの通常は終了しないエラーによって、Runbook の完了が停止します。 次の例は、ErrorActionPreference の使用方法を示しています。 スクリプトが停止するため、最後の Write-Output コマンドは実行されません。
$ErrorActionPreference = 'Stop'
Get-ChildItem -path nofile.txt
Write-Output "This message will not show"
Try Catch Finally
Try Catch Finally は、終了するエラーを処理するために PowerShell スクリプトで使用されます。 スクリプトでは、このメカニズムを使用して、特定の例外または一般的な例外をキャッチできます。 エラーを追跡または処理するには、catch ステートメントを使用する必要があります。 次の例では、存在しないファイルをダウンロードしようとしています。 これは、System.Net.WebException 例外をキャッチして、その他の例外の最後の値を返します。
try
{
$wc = new-object System.Net.WebClient
$wc.DownloadFile("http://www.contoso.com/MyDoc.doc")
}
catch [System.Net.WebException]
{
"Unable to download MyDoc.doc from http://www.contoso.com."
}
catch
{
"An error occurred that could not be resolved."
}
Throw
Throw を使用すると、終了するエラーを生成できます。 このメカニズムは、Runbook で独自のロジックを定義するときに役立ちます。 スクリプトが停止の必要な条件を満たしている場合は、throw ステートメントを使用して停止できます。 次の例では、このステートメントを使用して、必要な関数パラメーターを示します。
function Get-ContosoFiles
{
param ($path = $(throw "The Path parameter is required."))
Get-ChildItem -Path $path\*.txt -recurse
}
エラー
Runbook はエラーを処理する必要があります。 Azure Automation では、終了するエラーと終了しないエラーの 2 種類の PowerShell エラーがサポートされます。
終了するエラーが発生すると、Runbook の実行は停止されます。 Runbook は、[失敗] のジョブ状態で停止します。
終了しないエラーの場合は、エラー発生後もスクリプトを継続できます。 終了しないエラーの例は、Runbook で、存在しないパスを指定して Get-ChildItem コマンドレットを使用したときに発生するものです。 PowerShell では、パスが存在しないことを確認して、エラーをスローし、次のフォルダーへと処理を継続します。 この場合のエラーでは、Runbook のジョブ状態は [失敗] に設定されず、ジョブが完了する可能性もあります。 終了しないエラー時に Runbook を強制的に停止するには、コマンドレットで ErrorAction Stop を使用できます。
プロセスの呼び出し
Azure サンドボックスで実行される Runbook では、実行可能ファイル (.exe ファイル) やサブプロセスなどのプロセスの呼び出しはサポートされていません。 その理由は、Azure サンドボックスは、基になるすべての API にアクセスできるとは限らないコンテナーで実行される共有プロセスであるためです。 サード パーティ製ソフトウェアや、サブプロセスの呼び出しを必要とするシナリオの場合は、Hybrid Runbook Worker で Runbook を実行する必要があります。
デバイスとアプリケーションの特性
Azure サンドボックス内の Runbook ジョブは、デバイスやアプリケーションの特性にアクセスできません。 Windows でパフォーマンス メトリック (一般的なものはメモリや CPU の使用率など) のクエリを実行するために使用される最も一般的な API は WMI です。 ただし、クラウドで実行されているジョブでは Web-Based Enterprise Management (WBEM) の Microsoft による実装にアクセスできないため、どの API が使用されるかは問題ではありません。 このプラットフォームは、デバイスとアプリケーションの特性を定義するための業界標準を提供する Common Information Model (CIM) に基づいて構築されています。
ウェブフックs
Azure DevOps Services や GitHub などの外部サービスを使用すると、Azure Automation で Runbook を開始できます。 この種類の開始を行うために、サービスでは 1 つの HTTP 要求を介して Webhook を使用します。 Webhook を使用すると、完全な Azure Automation 機能を実装せずに Runbook を開始できます。
共有リソース
クラウド内のすべての Runbook 間でリソースを共有するために、Azure では、"フェア シェア" と呼ばれる概念が使用されています。 3 時間以上実行されているジョブがあると、フェア シェアの下、Azure はそれらのジョブを一時的にアンロードまたは停止します。 PowerShell の Runbook と Python の Runbook のジョブは停止されて再起動されず、ジョブの状態は [停止済み] になります。
長時間実行される Azure Automation タスクの場合は、Hybrid Runbook Worker の使用をお勧めします。 Hybrid Runbook Worker はフェア シェアによって制限されず、Runbook が実行できる時間に制限がありません。 その他のジョブの制限は、Azure サンドボックスと Hybrid Runbook Worker の両方に適用されます。 Hybrid Runbook Worker は 3 時間のフェア シェア制限を受けませんが、予期しないローカル インフラストラクチャの問題からの再起動がサポートされる worker で実行されるように Runbook を開発する必要があります。
もう 1 つのオプションは、子 Runbook を使用して Runbook を最適化することです。 たとえば、複数のデータベースに対するデータベース操作など、複数のリソースに対する同じ機能によって Runbook がループする可能性があります。 このような機能は、子 Runbook に移動し、Start-AzAutomationRunbook を使用して親 Runbook でそれを呼び出すことができます。 子 Runbook は別々のプロセスで並列に実行されます。
子 Runbook を使用すると、親 Runbook の完了までにかかる合計時間が短縮されます。 Runbook で子の完了後にまだ実行する操作がある場合、Get-AzAutomationJob コマンドレットを使用して、子 Runbook のジョブ状態を確認できます。
次のステップ
- PowerShell Runbook の使用を開始するには、「チュートリアル: PowerShell Runbook の作成」を参照してください。
- Runbook を操作するには、「Azure Automation で Runbook を管理する」を参照してください。
- PowerShell の詳細については、PowerShell のドキュメントを参照してください。
- PowerShell コマンドレットのリファレンスについては、「Az.Automation」をご覧ください。