前回（vol.116）説明した更新プログラムの確認とインストールを自動運用するためのメンテナンス構成のオプションに、メンテナンス期間の前後にカスタムアクションを実行する「事前（プレ）/事後（ポスト）イベント」を作成できることについて少しだけ触れました。事前/事後イベントでは、さまざまな方法（Logic Apps、Azure Functions、Webhook、ストレージキュー、ハイブリッド接続、Service Busキュー）を使用してカスタムアクションを実行できます。
Azure Update ManagerはAzure VMとAzure以外のWindows/Linuxマシンの管理に対応していますが、同様にそれらに対応しているプロセスオートメーション機能として「Azure Automation Hybrid Runtime Worker（ハイブリッドWorker）」があります。このRunbookをメンテナンス構成からどのように呼び出すのかはひとまず置いておいて、ハイブリッドWorkerについて少し勉強しましょう。
Azure AutomationのRunbookとハイブリッドWorker
Azure AutomationのRunbookはPowerShellまたはPythonスクリプトの実行に対応したプロセスオートメーションサービスです。既定では、RunbookはAzureのクラウドプラットフォームが提供するランタイム環境で実行されますが、「ハイブリッドWorkerグループ」を作成すると、Azure VMやAzure以外のマシンのWorkerとしてグループ化して、高可用性と負荷分散機能を持つ、高パフォーマンスのランタイム環境を提供できます（画面1）。Azureのランタイム環境からは、他社のクラウドやオンプレミスのリソースにアクセスできないことがありますが、ハイブリッドWorkerグループを使用すればそのようなローカルリソースを管理するために使用することもできます。この機能は、「Azure Automation Hybrid Runbook Worker」と呼ばれるものです。
Automation Hybrid Runbook Worker の概要｜Azure（Microsoft Learn）
画面1 Azure AutomationのRunbookは、Azure（既定）またはハイブリッドWorkerグループを選択して実行できる
ハイブリッドWorkerグループは、Azure VMおよびAzure以外の場所（オンプレミスや他社クラウド）にあるVMおよび物理マシンをハイブリッドWorkerとして追加して作成することができ、WindowsとLinuxの両方に対応しています。ハイブリッドWorkerになるマシン側に必要なのは、Azure VMの場合はVMエージェント（Azure Windows VMエージェント/Azure Linux VMエージェント）、Azure以外のマシンの場合はAzure Arc対応サーバーのエージェント（Azure Connected Machineエージェント）です。これは、Azure Update Managerの場合も同様です。ハイブリッドWorkerとして機能するために必要なものは、これらのエージェントを通じて以下の拡張機能としてプッシュインストールされます。
- HybridWorkerExtension（種類: HybridWorkerForWindows/HybridWorkerForLinux）
ハイブリッドWorkerの機能は最近までLog Analyticsのエージェントベースでしたが、エージェントベースの機能は2024年8月末に廃止され、現在の拡張機能ベースに切り替わりました。しかし、公式ドキュメントでさえ、新旧の情報が混在しており、導入や使用に悩むかもしれません。インターネット上の他の情報も同様です。例えば、以前はLog Analyticsワークスペースが必須であり、Azure Automationアカウントにワークスペースをリンクする必要がありましたが、現在はその必要は全くありませんでした。以下に、既にAzure VMがあり、Azure以外のマシンがAzure Arcに接続されていることを前提に導入方法と一般的な使用方法を説明します。Azure ArcへのWindows/Linuxマシンの接続については、この連載の以下の記事をご覧ください。
vol.114 オンプレのWindows ServerをAzure Arcに接続する｜Azure Update Managerでサーバー更新管理（3）
vol.115 オンプレのLinuxマシンをAzure Arcに接続する｜Azure Update Managerでサーバー更新管理（4）
なお、Azure Automationは有料のサービスです。料金については、以下のページで確認してください。
Automation の価格｜Azure（Microsoft）
Azure Automationアカウントの作成
Azureポータルで「Automationアカウント」ブレードを開き、「＋作成」をクリックして、Automationアカウントを作成します。「Automationアカウントの作成」ページの「基本」タブでは、サブスクリプション、リソースグループ、リージョン（地域）を選択し、Automationアカウント名を入力します（画面2）。「詳細設定」タブ以降はすべて既定値（マネージドID: システム割り当て、ネットワーク: パブリックアクセス）のまま「確認および作成」タブで「作成」をクリックします。
画面2 Automationアカウントを作成する。「基本」タブ以外は既定値で構わない
ハイブリッドWorkerグループの作成
Automationアカウントを作成したら、そのAutomationアカウントのブレードを開き、「プロセスオートメーション > ハイブリッドWorkerグループ」のページを開いて、「＋ハイブリッドWorkerグループの作成」をクリックします（画面3）。
画面3 「＋ハイブリッドWorkerグループの作成」をクリックする
「ハイブリッドWorkerグループの作成」ページの「基本」タブで名前を入力し、オプションで実行アカウントの資格情報を設定します（画面4）。既定は、システムアカウント（Windowsの場合はNT AUTHORITY¥SYSTEM、Linuxの場合はroot）の権限でプロセスが実行されることになります。
画面4 ハイブリッドWorkerグループの名前を設定する
次の「ハイブリッドWorker」タブで「＋マシンの追加」をクリックし、「ハイブリッドWorkerとしてマシンを追加する」ページで1台以上のAzure VMやAzure以外のマシン（Azure Arc対応サーバー）を選択して追加します（画面5）。今回は、AzureとオンプレミスにあるWindowsマシンをすべて追加しました。なお、Azure VMは実行中（VM running）であること、Azure以外のマシンは接続済み（Connected）であることが必要です。
PowerShell 7やPythonの共通の環境があれば、WindowsとLinuxを含むグループを作成できますが、そうでない場合はWindowsとLinuxでグループを分けたほうが良いでしょう。WindowsではWindows PowerShell 5.1のRunbookを標準で実行できます。Azure VMやAzure Arcに接続されたLinuxでは通常、PythonのRunbookを実行できます。
画面5 WorkerとしてAzure VMやAzure以外のマシンを1台以上追加する
「ハイブリッドWorkerグループの作成」ページの「確認と作成」タブで「作成」をクリックして、ハイブリッドWorkerグループの作成を開始します。なお、Azure VMやAzure以外のマシンに拡張機能「HybridWorkerExtension」がプッシュインストールされるため、ハイブリッドWorkerグループを利用可能になるまでにはしばらく時間がかかります。すべてのマシンでこの拡張機能の状態が「Provisonning succeeded（Azure VMの場合）/成功（Azure以外のマシンの場合）」になっていれば、準備は完了です（画面6）。
画面6 ハイブリッドWorkerとして追加したAzure VMやAzure以外のマシンに拡張機能「HybridWorkerExtension」がインストールされる
Runbookの作成とテスト
ハイブリッドWorkerグループの準備ができたら、PowerShellまたはPythonのRunbookを作成してテストします。Runbookは、「プロセスオートメーション > Runbook」ページで「＋Runbookの作成」をクリックして作成します。今回は、Windowsで標準で利用できるWindows PowerShell 5.1用のRunbookを作成します。「Runbookの作成」ページの「基本」タブで名前、種類、ランタイムバージョンを選択し、「確認と作成」タブで「作成」をクリックします（画面7）。
画面7 Windows PowerShell 5.1用のRunbookを作成する
Runbookが作成されると「PowerShell Runbookの編集」ページに遷移するので、次の簡単なスクリプトを「コマンドレット」に直接入力します（画面8）。このスクリプトの例では、実行しているコンピューターのホスト名を出力し、その後、IPアドレス「192.168.0.1」にpingを1回実行して、その結果を出力します。ちなみにこのIPアドレスは、Azure VMおよびオンプレミスのマシン（Hyper-V VM）が到達可能なHyper-V仮想スイッチのIPアドレス（プライベートIPアドレス）です。
| $ret = hostname Write-Output ("Ping from $ret") $ret = (ping -n 1 192.168.0.1) Write-Output ("$ret") #$ret=(whoami) #Write-Output ("$ret") |
画面8 PowerShell Runbookのサンプル
「テストウィンドウ」を開き、このRunbookをAzureとハイブリッドWorkerのそれぞれで実行してみました。既定の実行対象のAzureで実行した場合、pingに対する応答は当然ありません。一方、ハイブリッドWorkerグループを選択して実行した場合、応答が確認できます。この結果から、ハイブリッドWorkerがローカルリソースにアクセスできるという点が確認できたと思います（画面9）。スクリプトでコメントアウトしている行を有効にすれば、システム権限（NT AUTHORITY¥SYSTEM）で任意のコマンドラインを実行できることもわかるでしょう。今回は「ws2025vm02」というコンピューター名のハイブリッドWorkerが使用されましたが、1台以上のマシンを含むハイブリッドWorkerグループでどのハイブリッドWorkerが選択されるかを利用者が指定することはできません。これがハイブリッドWorkerグループの高可用性と負荷分散の機能です。
画面9 ハイブリッドWorkerでRunbookを実行すると、Azureではアクセスできないローカルリソースにアクセス可能（この例では画面下のプライベートネットワークへの到達）
テストしたRunbookは「公開」することで、利用可能な状態になります。「プロセスオートメーション > Runbook」ページから手動で開始し、ハイブリッドWorkerグループを選択して実行することができます（前出の画面1）。また、スケジュールを作成して、Runbookにリンクして自動実行させたり、Webhookを追加して外部から呼び出したりできるようになります。
ハイブリッドWorkerの機能を利用して、Azure VMやAzure以外のマシンのOS環境で何らかのタスクを実行させたいという場合は、1つのWorker（Azure VMまたはAzure Arc対応サーバー）だけを含むハイブリッドWorkerグループを作成する必要があります。そのため、作成したハイブリッドWorkerグループからすべてのハイブリッドWorker（マシン）を削除し*1、その後、このハイブリッドWorkerグループは削除しました。そして、Azure VMやAzure以外のマシンに一対一で対応した複数のハイブリッドWorkerグループを作成しました（画面10）。次回は、これらのハイブリッドWorkerグループと、カスタムスクリプトを含むRunbook、そしてAzure Update Managerのメンテナンス構成を連携させ、メンテナンス（更新プログラムのインストール、必要に応じて再起動）の前後に管理タスクを実行させる方法を紹介します。
*1 ハイブリッドWorkerグループからマシンを削除すると、そのマシンから拡張機能「HybridWorkerExtension」がアンインストールされます。ハイブリッドWorkerグループを再作成する場合は、各マシンから拡張機能が削除されたことを確認してから、ハイブリッドWorkerとして追加してください。タイミングを誤ると、いつまでたっても拡張機能の状態が成功にならなかったり、インストールが失敗したりすることがあります。
画面10 Azure Update Managerとの連携のために、Azure VMやAzure以外のマシンに一対一で対応した複数のハイブリッドWorkerグループを作成した
