パッチ適用プロセス

パッチソリューションの主なユーザーは、アプリケーション開発チームと運用チームです。各アプリケーションは通常、開発、テスト (統合、ユーザー承認など) 、本番環境など、複数の環境にデプロイされます。アプリケーションチームは、パッチが本番環境に適用された時点でテスト済みで、アプリケーションに悪影響がないことが確認されているように、環境ごとにパッチ適用スケジュールを計画する必要があります。

以下のワークフローは、複数の環境にデプロイされているアプリケーションのパッチ適用期間を計画する方法と、タグを設定する方法の例を示しています。

• ステップ 1. 各アプリケーションチームは、さまざまな環境内のサーバーのメンテナンスウィンドウを計画し、それに応じてサーバーのパッチグループとメンテナンスウィンドウを表すタグを設定します。

  • [パッチグループ] タグは、特定のパッチベースラインの対象となるアプリケーション環境内のサーバーを表します。パッチグループは、正しい一連のインスタンスに、正しいパッチベースラインのデプロイを確認するのに役立ちます。パッチグループはまた、パッチが適切にテストされる前に運用環境に展開することを回避するのにも役立ちます。

  • アプリケーションサーバーに複数のオペレーティングシステムが含まれている場合、アプリケーションチームは環境とオペレーティングシステムの組み合わせに基づいてパッチグループを作成します。パッチグループは 1 つのパッチベースラインにのみ登録でき、インスタンスは 1 つのパッチグループにのみ属することができます。

    例：appname-DEV-WIN および appname-DEV-RHEL

  • [メンテナンスウィンド] ウタグは、サーバにパッチを適用するスケジュールを表します。パッチグループ内のすべてのサーバーが同じメンテナンスウィンドウ内にある必要があります。メンテナンスウィンドウタグは、定義した Lambda 関数が式を簡単に解析できるように、cron 式と rate 式の一貫した形式に従う必要があります。(このガイドでは、このラムダ関数を automate-patch と呼ぶことにする)。

    例：schedule-duration-cutoff-timezone

    cron(0 2 ? * SAT#3 *) は毎月第 3 土曜日の午前 2:00 を表します。cron 式と rate 式の詳細については、「Systems Manager ドキュメント」 を参照してください。

• ステップ 2。Systems Manager Patch Manager は、定義されたコンフィギュレーションに基づき、オペレーティング・システム固有のパッチ・ベースラインを通じて、新しいパッチを定期的に提供します。

  • オペレーティングシステムごとに、クラウド環境全体のインスタンスに適用する必要がある承認ルールとパッチを含むカスタム パッチベースラインを定義できます。

• ステップ 3。カスタム自動化コードにより、[パッチグループ] と[メンテナンスウィンドウ] タグに基づいてパッチを適用するように Patch Manager を構成し、パッチを開発環境に適用します。

  • パッチ適用が完了すると、アプリケーション開発チームとサポートチームがアプリケーションをテストし、すべてが正しく動作することを確認します。

  • 新しいパッチでアプリケーションに問題が発生した場合、アプリケーションチームはクラウドサービスチームに、メンテナンスウィンドウを無効にするか、パッチタスク実行の登録を解除して、他のパッチグループや他の環境へのパッチ適用を停止するよう依頼します。

• ステップ 4。開発環境のパッチが成功したら、本番環境以外の環境にもパッチを適用します。開発環境と同様に、アプリケーションはテストされ、すべての非本番環境で正しく動作することが検証されます。問題があれば、アプリケーションチームはクラウドサービスチームに本番環境へのパッチ適用を中止するよう要請します。

• ステップ 5. すべての非本番環境のパッチが成功した後、本番環境にパッチが適用されます。