• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。

# チュートリアル: アプリケーションの依存関係の更新、マネージドノードへのパッチ適用、およびアプリケーション固有のヘルスチェックの実行
<a name="aws-runpatchbaselinewithhooks-tutorial"></a>

多くの場合、マネージドノードは、最新のソフトウェア更新プログラムでパッチを適用した後に再起動する必要があります。ただし、安全対策を講じずに本番環境でノードを再起動すると、アラームの発動、不正なメトリクス データの記録、データ同期の中断など、いくつかの問題が発生する可能性があります。

このチュートリアルでは、AWS Systems Manager ドキュメント (SSM ドキュメント) `AWS-RunPatchBaselineWithHooks` を使用して、このような問題を回避する方法を学習します。これにより、複雑なマルチステップのパッチオペレーションを実現し、以下のことを達成できます。

1. アプリケーションへの新しい接続を防止

1. オペレーティングシステムの更新のインストール

1. アプリケーションのパッケージの依存関係の更新

1. システムの再起動

1. アプリケーション固有のヘルスチェックの実行

この例では、インフラストラクチャを次のようにセットアップしました。
+ 対象の仮想マシンは、マネージドノードとして Systems Manager に登録されます。
+ `Iptables` はローカルファイアウォールとして使用されます。
+ マネージドノードでホストされているアプリケーションは、ポート 443 で実行されています。
+ マネージドノードでホストされるアプリケーションは `nodeJS` アプリケーションです。
+ マネージドノードでホストされるアプリケーションは、pm2 プロセスマネージャーによって管理されます。
+ アプリケーションには、指定したヘルスチェックエンドポイントが既に存在します。
+ アプリケーションのヘルスチェックエンドポイントは、エンドユーザー認証を必要としません。エンドポイントにより、可用性を確立する際に組織の要件を満たすヘルスチェックを行うことが可能になります。(実際の環境では、`nodeJS` アプリケーションが実行中であり、リクエストをリッスンできることを確認するだけで十分な場合があります。また、キャッシュレイヤーまたはデータベースレイヤーへの接続が既に確立されていることを確認する必要があります)。

このチュートリアルの例は、デモンストレーションのみを目的としており、本番環境にそのまま実装することを意図していません。また、Systems Manager のツールである Patch Manager のライフサイクルフック機能は、`AWS-RunPatchBaselineWithHooks` ドキュメントとともに他の多数のシナリオをサポートできることに注意してください。次にいくつかの例を示します。
+ マネージドノードの再起動後にパッチを適用して再起動する前に、メトリクスレポート エージェントを停止します。
+ パッチを適用する前に、CRM または PCS クラスターからマネージドノードをデタッチし、ノードの再起動後に再アタッチします。
+ オペレーティングシステム (OS) の更新が適用された後、マネージドノードが再起動する前に、Windows Server マシン上のサードパーティーソフトウェア (Java、Tomcat、Adobe アプリケーションなど) を更新します。

**アプリケーションの依存関係を更新し、マネージドノードにパッチを適用し、アプリケーション固有のヘルスチェックを実行するには**

1. preinstallation スクリプトの SSM ドキュメントを次の内容で作成し、`NodeJSAppPrePatch` と名前を付けます。*your\$1application* をアプリケーションの名前に置き換えます。

   このスクリプトは、新しい受信リクエストを直ちにブロックし、既にアクティブなリクエストが完了するまで 5 秒間待ってからパッチ適用操作を開始します。`sleep` オプションでは、受信リクエストが完了するのに通常かかる秒数よりも長い秒数を指定します。

   ```
   # exit on error
   set -e
   # set up rule to block incoming traffic
   iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
   # wait for current connections to end. Set timeout appropriate to your application's latency
   sleep 5 
   # Stop your application
   pm2 stop your_application
   ```

   SSM ドキュメントの作成の詳細については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。

1. postinstall スクリプト用に次の内容を含む別の SSM ドキュメントを作成し、アプリケーションの依存関係を更新し、`NodeJSAppPostPatch` と名前を付けます。*/your/application/path* をお使いのアプリケーションへのパスに置き換えます。

   ```
   cd /your/application/path
   npm update 
   # you can use npm-check-updates if you want to upgrade major versions
   ```

1. アプリケーションをバックアップし、ヘルスチェックを実行するには、`onExit` スクリプト用に次の内容を含む別の SSM ドキュメントを作成します。この SSM ドキュメント `NodeJSAppOnExitPatch` の名前を付けます。*your\$1application* をアプリケーションの名前に置き換えます。

   ```
   # exit on error
   set -e
   # restart nodeJs application
   pm2 start your_application
   # sleep while your application starts and to allow for a crash
   sleep 10
   # check with pm2 to see if your application is running
   pm2 pid your_application
   # re-enable incoming connections
   iptables -D INPUT -j DROP -p tcp --syn --destination-port 
   # perform health check
   /usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
   ```

1. AWS Systems Manager のツールである State Manager で関連付けを作成し、以下の手順を実行してオペレーションを発行します。

   1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。

   1. ナビゲーションペインで、[**State Manager**] を選択し、[**Create association (関連付けの作成)**] を選択します。

   1. [**Name (名前)**] に、関連付けの目的を特定するのに役立つ名前を指定します。

   1. [**Document (ドキュメント)**] リストで、[`AWS-RunPatchBaselineWithHooks`] を選択します。

   1. [**Operation (オペレーション)**] で、[**Install (インストール)**] を選択します。

   1. (オプション) [**Snapshot Id**] では、GUID を指定します。これは、オペレーションの高速化と一貫性の確保のために生成します。この GUID は `00000000-0000-0000-0000-111122223333` と同じくらいシンプルです。

   1. [**Pre Install Hook Doc Name (インストール前のフックドキュメント名)**] に、「`NodeJSAppPrePatch`」と入力します。

   1. [**Post Install Hook Doc Name (インストール後のフックドキュメント名)**] に、「`NodeJSAppPostPatch`」と入力します。

   1. [**On ExitHook Doc Name (ExitHook ドキュメント名)**] に、「`NodeJSAppOnExitPatch`」と入力します。

1. **[Targets]** (ターゲット) では、タグの指定、ノードの手動選択、リソースグループの選択、またはすべてのマネージドノードの選択により、マネージドノードを特定します。

1. [**Specify schedule (スケジュールの指定)**] では、関連付けを実行する頻度を指定します。マネージドノードのパッチ適用では、週に 1 回が一般的な頻度です。

1. **[Rate control]** (レート制御) セクションで、複数のマネージドノードでの関連付けの実行方法を制御するオプションを選択します。一度に更新されるのは一部のマネージドノードであることを確認します。そうしないと、フリートのすべてまたはほとんどを同時にオフラインにすることになってしまいます。レート制御については、「[State Manager 関連付けのターゲットとレート制御について](systems-manager-state-manager-targets-and-rate-controls.md)」を参照してください。

1. (オプション) [**出力オプション**] で、コマンド出力をファイルに保存するには、[**S3 への出力の書き込みを有効にします**] ボックスをオンにします。ボックスにバケット名とプレフィックス (フォルダ) 名を入力してください。
**注記**  
S3 バケットにデータを書き込む機能を許可する S3 アクセス許可は、このタスクを実行する IAM ユーザーのものではなく、マネージドノードに割り当てられたインスタンスプロファイルのものです。詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」または「[ハイブリッド環境に IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。さらに、指定された S3 バケットが別の AWS アカウント にある場合は、マネージドノードに関連付けられたインスタンスプロファイルまたは IAM サービスロールに、そのバケットへの書き込みに必要なアクセス許可があることを確認してください。

1. **[関連付けの作成]** を選択します。