事前および事後イベントの管理 (プレビュー)
適用対象: ✔️ Windows VMs ✔️ Linux VM ✔️ オンプレミス環境 ✔️ Azure Arc 対応サーバー。
事前イベントと事後イベントを使用すると、セキュリティ パッチのインストールの前後にユーザー定義アクションを実行できます。 この記事では、Azure Update Manager で事前イベントと事後イベントを作成、表示、キャンセルを行う方法について説明します。
パブリック プレビュー用のサブスクリプションを登録する
Azure portal でパブリック プレビュー用にサブスクリプションを自己登録するには:
Azure portal にサインインし、[すべてのサービス] を選択します。
[すべてのサービス] ページで、[プレビュー機能] を検索します。
[プレビュー機能] ページで、[事前イベントと事後イベント] を検索して選択します。
機能を選択し、[登録] を選択してサブスクリプションを登録します。
事前イベントと事後イベントのスケジュールのタイムライン
事前イベントと事後イベントのスケジュールのタイムラインを理解するには、次の表を参照することをお勧めします。
たとえば、メンテナンス スケジュールが午後 3 時 00 分に開始するように設定され、ゲスト メンテナンス スコープのメンテナンス期間が 3 時間 55 分の場合、詳細は次のようになります:
時刻 | 詳細 |
---|---|
2:19 PM | マシンを編集したり、関連する事前イベントでスケジュールされたパッチを実行する 40 分前までマシンのスコープを動的に設定したりできます。 この時刻以降にスケジュールにアタッチされているリソースに変更が加えられた場合、リソースは現在の実行ではなく、後続のスケジュール実行に含まれます。 注 新しいスケジュールを作成する場合、または事前イベントを使用して既存のスケジュールを編集する場合は、事前イベントを実行するのにメンテナンス期間の前に少なくとも 40 分を必要とします。 この例では、午後 3 時 00 分にスケジュールを設定した場合、設定時刻の 40 分前 (つまり午後 2 時 19 分) にスコープを変更できます。 |
午後 2 時 20 分から午後 2 時 30 分まで | 事前イベントがトリガーされ、パッチのインストールの実行が開始される前に完了するまでに少なくとも 20 分かかります。 この例では、事前イベントは午後 2 時 20 分から午後 2 時 30 分の間に開始されます。 |
午後 2:50 | 事前イベントでは、パッチのインストールの実行が開始されるまでに少なくとも 20 分かかります。 注 - 事前イベントが 20 分を超えて実行され続ける場合は、事前イベントの実行状態に関係なく、パッチのインストールが開始されます。 - 現在の実行をキャンセルする場合は、スケジュールの 10 分前にキャンセル API を使用してキャンセルできます。 この例では、午後 2 時 50 分までに、スクリプトまたは Azure 関数コードからキャンセルできます。 キャンセル API が呼び出せない場合、または設定されていない場合は、パッチのインストールが続行されます。 この例では、事前イベントは午後 2 時 50 分までにタスクを完了する必要があります。 現在の実行をキャンセル場合、キャンセル API を呼び出すことができる最も遅い時刻は午後 2 時 50 分です。 |
3:00 PM | メンテナンス構成で定義されているように、スケジュールは指定された時刻にトリガーされます。 この例では、スケジュールは午後 3 時 00 分にトリガーされます。 |
6:55 PM | 定義されたメンテナンス期間が完了すると、事後イベントがトリガーされます。 2 時間の短いメンテナンス期間を定義した場合、メンテナンス後のイベントは 2 時間後にトリガーされ、指定された 2 時間より前に (つまり 1 時間 50 分で) メンテナンス スケジュールが完了すると、事後イベントが開始されます。 この例では、メンテナンス期間が最大に設定されている場合、午後 6 時 55 分までに修正プログラムのインストール プロセスが完了します。それより短いメンテナンス期間が設定されている場合は、午後 5 時 00 分までにパッチのインストール プロセスが完了します。 |
午後 7:15 | パッチのインストール後、事後イベントは 20 分間実行されます。 この例では、事後イベントは午後 6 時 55 分に開始され、午後 7 時 15 分までに完了します。短いメンテナンス期間が設定されている場合は、事後イベントは午後 5 時 00 分にトリガーされ、午後 5 時 20 分までに完了します。 |
次の点に注意することをおすすめします。
- 新しいスケジュールを作成する場合、または事前イベントを使用して既存のスケジュールを編集する場合、事前イベントを実行するには、メンテナンス期間の開始 (上記の例では午後 3 時) の少なくとも 40 分前に必要です。そうしないと、現在のスケジュールされた実行が自動的に取り消されます。
- 事前イベントは、スケジュールされたパッチの実行の 30 分前にトリガーされ、事前イベントが完了するまで少なくとも 20 分かかります。
- 事後イベントは、パッチのインストールが完了した直後に実行されます。
- 現在のパッチの実行を取り消すには、スケジュールメンテナンス時間の少なくとも 10 分前にキャンセル API を使用します。
既存のスケジュールで事前イベントと事後イベントを構成する
既存のスケジュールで事前イベントと事後イベントを構成し、1 つのスケジュールに複数の事前イベントと事後イベントを追加できます。 事前イベントと事後イベントを追加するには、次の手順に従います:
Azure portal にサインインし、[Azure Update Manager] に移動します。
[管理] で、[マシン]、[メンテナンス構成] の順に選択します。
[メンテナンス構成] ページで、事前イベントと事後イベントを追加するメンテナンス構成を選択します。
選択した [メンテナンス構成] ページで、[設定] で [イベント] を選択します。 または、[概要] で [メンテナンス イベントの作成] のカードを選択します。
[+イベント サブスクリプション] を選択して、メンテナンス前/メンテナンス後イベントを作成します。
[イベント サブスクリプションの作成] ページで、次の詳細を入力します:
[イベント サブスクリプションの詳細] セクションで、適切な名前を指定します。
スキーマは Event Grid スキーマのままにします。
[トピックの詳細] セクションで、[システム トピック名] に適切な名前を指定します。
[イベントの種類] セクションの [イベントの種類にフィルターを適用] で、エンドポイントまたは送信先にプッシュするイベントの種類を選択します。 [メンテナンス前イベント] と [メンテナンス後イベント] を選択できます。
[エンドポイントの詳細] セクションで、応答を受信するエンドポイントを選択します。 これは、顧客が事前イベントまたは事後イベントをトリガーするのに役立ちます。
[作成] を選択して、既存のスケジュールで事前イベントと事後イベントを構成します。
Note
- 事前イベントと事後イベントは、予定メンテナンス構成レベルでのみ作成できます。
- システム トピックはメンテナンス構成ごとに自動的に作成され、すべてのイベント サブスクリプションが EventGrid のシステム トピックにリンクされます。
- 事前および事後イベントの実行は、予定メンテナンス期間の範囲外です。
事前イベントと事後イベントを表示する
事前イベントと事後イベントを表示するには、次の手順に従います:
- Azure portal にサインインし、[Azure Update Manager] に移動します。
- [管理] で、[マシン]、[メンテナンス構成] の順に選択します。
- [メンテナンス構成] ページで、事前イベントと事後イベントを追加するメンテナンス構成を選択します。
- [概要] を選択し、[メンテナンス イベント] にチェックを入れます。
事前イベントと事後イベントを削除する
事前イベントと事後イベントを削除するには、次の手順に従います:
Azure portal にサインインし、[Azure Update Manager] に移動します。
[管理] で、[マシン]、[メンテナンス構成] の順に選択します。
[メンテナンス構成] ページで、事前イベントと事後イベントを追加するメンテナンス構成を選択します。
選択した [メンテナンス構成] ページで、[設定] で [イベント] を選択します。 または、[概要] で [メンテナンス イベントの作成] のカードを選択します。
グリッドから削除するイベントの名前を選択します。
選択した [イベント] ページで、[削除] を選択します。
Note
- すべての事前イベントと事後イベントがメンテナンス構成から削除された場合、システム トピックは EventGrid から自動的に削除されます。
- EventGrid サービスからシステム トピックを手動で削除しないことをおすすめします。
事前イベントからスケジュールをキャンセルする
スケジュールをキャンセルには、事前イベントでキャンセル API を呼び出して、Runbook スクリプトまたは Azure 関数コードにあるキャンセル プロセスを設定する必要があります。 ここでは、いつからスケジュールをキャンセルする必要があるかという条件を定義する必要があります。 システムは、事前イベントの状態に基づいてスケジュールを監視しておらず、また自動的にキャンセルしません。
キャンセルには次の 2 種類があります:
- ユーザーによるキャンセル - スクリプトまたはコードからキャンセル API を呼び出すとき。
- システムによるキャンセル - 内部エラーが原因でシステムがキャンセル API を呼び出す場合。 これは、スケジュールされたパッチ適用ジョブの 30 分前に、システムが事前イベントを顧客のエンドポイントに送信できない場合にのみ行われます。
Note
システムによるキャンセルが行われた場合、システムによる事前イベントの実行に失敗したため、今後予定されているパッチ適用ジョブがキャンセルされます。
重要
予定メンテナンス ジョブがキャンセル API を使用してユーザーによってキャンセルされた場合、または内部エラーが原因でシステムによってキャンセルされた場合は、事後イベントは (サブスクライブされている場合)、ユーザーが構成したエンドポイントに送信されます。
キャンセルの状態を表示する
キャンセルの状態を表示するには、次の手順に従います:
JSON のエラー メッセージからキャンセルの状態を表示できます。 JSON は、Azure Resource Graph (ARG) から取得できます。 対応するメンテナンス構成は、キャンセル API を使用してキャンセルされます。
次のクエリを使うと、特定のスケジュールまたはメンテナンス構成の VM のリストを表示できます:
maintenanceresources
| where type =~ "microsoft.maintenance/maintenanceconfigurations/applyupdates"
| where properties.correlationId has "/subscriptions/your-s-id/resourcegroups/your-rg-id/providers/microsoft.maintenance/maintenanceconfigurations/mc-name/providers/microsoft.maintenance/applyupdates/"
| order by name desc
your-s-id
: 事前イベントまたは事後イベントを含むメンテナンス構成が作成されるサブスクリプション IDyour-rg-id
: メンテナンス構成が作成されるリソース グループ名mc-name
: 事前イベントのメンテナンス構成の名前が作成されます
何らかの理由でメンテナンス ジョブがシステムによってキャンセルされた場合、対応するメンテナンス構成の Azure Resource Graph から取得される JSON のエラー メッセージは、"メンテナンス スケジュールが内部プラットフォーム エラーが原因でキャンセルされました" となります。
キャンセル API を呼び出す
C:\ProgramData\chocolatey\bin\ARMClient.exe put https://management.azure.com/<your-c-id-obtained-from-above>?api-version=2023-09-01-preview "{\"Properties\":{\"Status\": \"Cancel\"}}" -Verbose
Note
上記の ARG クエリから受信した関連付け ID を置き換え、それをキャンセル API で置き換える必要があります。
例
C:\ProgramData\chocolatey\bin\ARMClient.exe put https://management.azure.com/subscriptions/eee2cef4-bc47-4278-b4f8-cfc65f25dfd8/resourcegroups/fp02centraluseuap/providers/microsoft.maintenance/maintenanceconfigurations/prepostdemo7/providers/microsoft.maintenance/applyupdates/20230810085400?api-version=2023-09-01-preview "{\"Properties\":{\"Status\": \"Cancel\"}}" -Verbose
次のステップ
- 問題と回避策については、トラブルシューティングを参照してください
- 事前シナリオと事後シナリオの概要については、
- 事前イベントと事後イベントの一般的なシナリオを参照してください
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示