AWS Patch Managerを活用したOrganization内のDev/Prod環境パッチデプロイ戦略②
はじめに
Septeni Japan株式会社でインフラエンジニアを担当している金と申します。
前回の第1部に続き、第2部では、本番環境において安全かつ効率的にパッチを適用するための具体的な方法について2つ紹介します。
前提
第1部でご説明した手順に従い、管理アカウントのPatch Policyを使用した自動パッチ適用設定が完了していることが前提となりますので、まだご覧になっていない場合は、まず第1部をご確認ください。
概要
開発環境では、Patch Managerを使用して、指定したパッチをスケジュールに沿って自動的に適用することが可能です。しかし、本番環境では、サービスへの影響を最小限に抑えるため、エンジニアがサーバの状況を確認しながら手動でパッチを適用したいかつ、開発環境で十分に検証済みのパッチのみを適用したいというニーズがあると考えられます。
本記事では、このような課題を解決する2つの方法を説明します。
- State Manager Associationの活用方法
- Patch Manager「Patch now」の活用方法
方法1:State Manager Associationの活用方法
第1部で紹介した、OrganizationのメンバーアカウントにデプロイされたState Manager Associationと、管理アカウントのS3に保存されているパッチベースラインオーバーライドを使用して、本番環境にパッチを適用します。
導入手順
- 開発環境用に作成されたState ManagerのAssociation情報を確認
- Document「AWS-RunPatchBaseline」を使用してPatch Scan & Install用に作成されたAssociation IDを選択します。
- 該当するAssociation IDおよびParametersタブに記載されているBaselineOverrideのS3 URLを記録しておきます。
- 本番環境にパッチを適用するための新規Associationの作成
- State Managerの画面から「Create association」を選択します。
- 適切なAssociation名を指定し、Documentの検索欄に「AWS-RunPatchBaseline」と入力して選択します。
- Parametersの設定では、手順1で取得した開発環境用のAssociation IDおよびBaselineOverrideのS3 URLを記載します。さらに、ScanおよびInstallのオプションを選択し、適用後に再起動を行うかどうかを指定します。
- Target selectionでは以下のいずれかの方法で適用対象を選択できます:
- タグ、手動選択、リソースグループ、全てのインスタンス
- ここでは例としてタグを選択し、key:env、value:prodと設定します。設定後、「Add」をクリックします。
- Specify scheduleでは今回は手動適用のため「No schedule」を選択します。
- その他のオプションは空欄のまま「Create association」をクリックして作成します。
- Associationの実行と確認
- 作成されたAssociationを確認します。
- 該当するAssociationを選択し、画面上部の「Apply association now」を選択して実行します。
- Stateが「Success」に変更されると、Associationの「Execution history」から実行されたコマンドや適用されたパッチのログを確認できます。
- Systems ManagerのFleet Managerを使用して、対象インスタンスの「Properties」タブの「Patch」セクションから適用されたパッチの内容を確認できます。
- 今回本番環境用に作成したAssociationは、Patch Managerのダッシュボード下部「Non-patch policy-based recurring tasks」に残ります。また、State ManagerのAssociationリストからも確認できます。次回以降は、こちらをそのまま使用することができます。
方法2:Patch Manager「Patch now」の活用方法
メンバーアカウントごとにPatch ManagerのPatch Baselineを作成し、「Patch now」機能を利用して本番環境へのパッチ適用を行います。
導入手順
- メンバーアカウントでOSごとにPatch Baseline作成
- Patch Managerメニューから「Create patch Baseline」を選択します。
- Patch Baseline名と対象OSを選択します。
- 🟠注意1:「Patch now」はDefault Patch Baselineを参照してパッチを適用するため、利用するBaselineを必ずDefault Baselineとして設定する必要があります。
- 🟠注意2:2022年12月22日以前にPatch Managerで作業を行ったことがないアカウント**では、コンソール上でDefault Baselineの設定ができません。そのため、CLIを利用して作業を行う必要があります。
# 現在の設定を確認
$ aws ssm describe-patch-baselines \
--p your_profile
{
"BaselineId": "arn:aws:ssm:ap-northeast-1:123456789098:patchbaseline/pb-0be4fdf9cb953577d",
"BaselineName": "AWS-AmazonLinux2023DefaultPatchBaseline",
"OperatingSystem": "AMAZON_LINUX_2023",
"BaselineDescription": "Default Patch Baseline for Amazon Linux 2023 Provided by AWS.",
"DefaultBaseline": true # AWS側で作成したベースライン
},
{
"BaselineId": "pb-0ec903d9f1e3a44cb",
"BaselineName": "Patch-Baseline-Amazon-Linux2023",
"OperatingSystem": "AMAZON_LINUX_2023",
"BaselineDescription": "Patch-Baseline-Amazon-Linux2023",
"DefaultBaseline": false # 今回作成したベースライン
}
# AMAZON_LINUX_2023のデフォルトベースラインを変更
$ aws ssm register-default-patch-baseline \
--baseline-id pb-0ec903d9f1e3a44cb \
--p your_profile
{
"BaselineId": "pb-0ec903d9f1e3a44cb" # 今回作成したベースラインID
}
# 変更されたことを確認
$ aws ssm describe-patch-baselines \
--p your_profile
{
"BaselineId": "arn:aws:ssm:ap-northeast-1:123456789098:patchbaseline/pb-0be4fdf9cb953577d",
"BaselineName": "AWS-AmazonLinux2023DefaultPatchBaseline",
"OperatingSystem": "AMAZON_LINUX_2023",
"BaselineDescription": "Default Patch Baseline for Amazon Linux 2023 Provided by AWS.",
"DefaultBaseline": false # AWS側でで作成したベースライン
},
{
"BaselineId": "pb-0ec903d9f1e3a44cb",
"BaselineName": "Patch-Baseline-Amazon-Linux2023",
"OperatingSystem": "AMAZON_LINUX_2023",
"BaselineDescription": "Patch-Baseline-Amazon-Linux2023",
"DefaultBaseline": true # 今回作成したベースライン
}
- 適用する対象パッチなどの詳細設定は、開発環境で検証済みのパッチのみを適用するため、開発環境と同じ設定にします。
- 🟠注意3:Auto-approval設定を開発環境と同じ日数にすると、開発環境で適用されていないパッチが本番環境でのみ適用される可能性があります。そのため、開発環境の設定日数に、本番環境での適用遅延日数を加えた日数をAuto-approvalに設定する必要があります。
- 「Patch now」の実行
- Patch Manager コンドール右上の「Patch now」を選択します。
- Scan、Install、Reboot の設定を選択し、パッチ適用対象のインスタンスを選択します。
- ここでは Tag を使用して指定していますが、インスタンスの手動選択や Resource Group からの選択も可能です。
- Tag の設定後は「Add」をクリックして Tag を登録する必要があります。
- 設定が完了したら右下の「Patch now」をクリックすることで対象インスタンスにパッチが適用されます。
- 「Patch Now」を実行すると、State ManagerにAssociationが作成され、Patch Managerのダッシュボード下部「Non-patch policy-based recurring tasks」に残ります。また、State ManagerのAssociationリストからも確認できます。
- 次回パッチを適用する際、適用条件やAuto-approvalの日数が同じ場合は、このAssociationをそのまま利用します。一方で、設定を変更する場合は、新たに「Patch Now」を実行する必要があります。
まとめ
本番環境でのPatch適用方法について、2つの方法を紹介しましたが、それぞれのメリット・デメリットを簡単にまとめました。
区分 | State Manager Association | Patch Manager「Patch now」 |
---|---|---|
メ リ ッ ト |
・開発環境で検証済みの設定(AssociationおよびBaselineOverride)を本番環境で再利用できるため、作業効率が良い | ・「Patch now」ボタンをクリックするだけでインスタンスにパッチを即時適用可能 ・Auto-approvalを変更できるため、テスト環境と本番環境の適用タイミングを効果的に管理可能 |
デ メ リ ッ ト |
・ステートマネージャーの設定や実行プロセスが複雑 ・Auto-approvalを変更することができないため、テスト環境と本番環境の適用時間差が短い場合のみ有効 |
・メンバーアカウントでOSごとにPatch Baselineを作成する必要があるため、初期工数が増加 ・場合によってはCLIのみでDefault Baselineの設定が可能で、設定作業が複雑になる |
どちらの方法も本番環境におけるPatch管理を効率化するために有効ですが、組織の要件や運用スタイルに合わせて適切な方法を選択することが重要です。
本記事が皆様のAWS EC2環境の安全性向上と効率的な運用に少しでもお役に立てれば幸いです。
最後までお読みいただき誠にありがとうございました。
Discussion