SSM 使ってみましょうワークショップ回
みなさんは普段、AWS Systems Manager を使われているでしょうか。
AWS Systems Manager は、AWS 環境を管理・運用していくためのサービスです。
大量のサーバーの OS のバージョン、アプリケーションのバージョン、パッチ適用の有無などを一元管理するためのサービスです。
管理対象は、Amazon EC2 だけでなくオンプレミス環境のサーバーまで幅広くサポートします。
増え続ける機能
Systems Manager は 2015 年に、Amazon EC2 Simple Systems Manager という名称でリリースされました。なので、この後も何度かポリシーの記述まわりで登場しますが略称は SSM です。
当初は、ドメイン参加や、msi パッケージのインストールなど Windows OS に特化した機能のみでリリースされました。
それから、はや 8 年。年々、機能が増え続けて、2023 年 5 月現在、カテゴリ分けしないと判別が難しいほどに機能が充実しています。
アプリケーション管理
ノード管理
何十、何百、多い場合は 1,000 台以上の仮想マシンに 1 台ずつログインして、インストールコマンドを投入していたら時間がいくらあっても足りません。
そうした大量のサーバー管理を実現するために、さまざまな機能を充実させながら、Systems Manager は進化してきました。
ハンズオンの概要
本日のハンズオンでは、初心者には多機能過ぎて使いこなせない、圧倒されてしまう AWS Systems Manager を使い始めるための第一歩を学びます。
具体的には、ノード管理機能であるフリートマネージャー、セッションマネージャー、Run Command、パッチマネージャー の一部の機能を操作するハンズオンです。
本ハンズオンが、みなさまのサーバー管理のきっかけになれば大変幸いです。
ハンズオンに必要なもの
- AWS アカウント
- Administrator 権限が付与された IAM ユーザー
ハンズオンにかかるランニングコスト
本ハンズオンで利用する EC2 インスタンスは t4g.nano です。
t4g ファミリーは、イスラエルの Annapurnalabs (アナプルマ・ラボ) が開発した CPU 「Graviton2」 が搭載された共有型のインスタンスです。
アナプルマ・ラボは Amazon.comの子会社です。(CPU の写真は こちら から引用)
2023 年 5 月現在、0.0054 USD/h で利用できますので、例えば今日のハンズオンで 1.5 時間稼働させたとしても、1 円程度で体験いただくことができます。
IAM
従来の設定 (IAM インスタンスプロフィールロールの設定)
これまで、SSM を利用するために要件がありました。
- インスタンスに SSM エージェントがインストールされ、稼働していること
- インスタンスから HTTPS のアウトバウンドトラフィックが確保されていること (インバウンドは不要)
- インスタンスに適切な IAM インスタンスプロフィールロールがアタッチされていること
2023 年 2 月に Default Host Management Config (略して DHMC) が登場し、それぞれのインスタンスに IAM インスタンスプロフィールロールをアタッチするのが必須ではなくなりました。(初心者支部 #55 イベント の LT で紹介)
DHMC 機能を使った接続方法はご紹介をするのですが、設定後反映するのに時間がかかるのと、SSM Agent のバージョンが 3.2.582.0 以上でないとロールレスで接続ができないため、本ハンズオンは従来の IAM プロフィールロールをアタッチする方法で進めます。
それでは、早速ロールを作成/設定して、セッションマネージャー経由でインスタンスに接続をしてみましょう。
- IAM ロールの管理ページ にアクセスします。
- [ロールを作成] ボタンをクリックします。
- 信頼されたエンティティを選択 画面で、EC2 を選択し、[次へ] ボタンをクリックします。
-
AmazonSSMManagedInstanceCoreを検索して、チェックボックスにチェックを入れます。[次へ] ボタンをクリックします。
- 任意の名前をつけます。ここでは
AmazonSSMManagedInstanceCoreEC2InstanceRoleとします。
- ページ下部の [ロールの作成] ボタンをクリックします。
AWS CloudFormation で環境を展開する
セッションマネージャー経由でインスタンスに接続する準備が整いましたので、環境をデプロイします。
時間短縮のために、VPC 作成と EC2 インスタンスのデプロイまでを CloudFormation で行い、その後のオペレーションを手作業で学んでいきます。
こちら から CloudFormation をダウンロードしてください。
- 東京リージョンの CloudFormation コンソール を開きます。
- 東京リージョンであることを確認します。
東京リージョンでない場合には、東京リージョンに設定してください。
初めて CloudFormation を展開する方は、以下の画面が表示されていると思いますので、[スタックの作成] ボタンをクリックしてください。
- 一つでも CloudFormation スタックを展開してある環境だと、スタックリストが表示されていると思いますので、[スタックの作成] ボタンをクリックして、[新しいリソースを作成(標準)] を選択します。
- スタックの作成 画面の画面に遷移したら、テンプレートの指定 で、以下のように設定し、[次へ]ボタンをクリックします。
A. テンプレートソースは、「テンプレートファイルのアップロード」 を選択
B. テンプレートファイルのアップデート で [ファイルの選択] ボタンをクリックし、ダウンロードした yaml ファイルを選択
- ページ下部の [次へ] ボタンをクリックすると、[スタックの詳細を指定] 画面に遷移するので、スタックの名前を指定します。
ここでは、vpc-and-ec2と入力します。[次へ] ボタンをクリックします。
- スタックオプションの設定画面では、（デフォルトの設定のまま、）[次へ]ボタンをクリックします。
〜中省略〜
- レビュー vpc-and-ec2（任意のスタック名）画面で、（デフォルトの設定のまま、） [送信] ボタンをクリックします。
〜中省略〜
- デプロイが始まります。デプロイ完了までに数分かかります。
右上の [更新] ボタンをクリックすると、デプロイ状況が確認できます。左上での [更新] ボタンをクリックし、CREATE_IN_PROGRESS から、 CREATE_COMPLETE になれば、デプロイは完了です。
＜デプロイ中＞
＜デプロイ完了＞
CloudFormation はうまく実行できましたでしょうか。
CloudFormation スタックを流すと、VPC と EC2 インスタンスができます。
| Service | Resource | Head |
|---|---|---|
| VPC | VPC | jawsug-bgnr-handson-vpc |
| ^ | サブネット | jawsug-bgnr-handson-PublicSubnet-a |
| ^ | サブネット | jawsug-bgnr-handson-PublicSubnet-c |
| ^ | ルートテーブル | jawsug-bgnr-handson-PublicRoute |
| ^ | インターネットゲートウェイ | jawsug-bgnr-handson-igw |
| ^ | セキュリティグループ | jawsug-bgnr-handson-sg-web |
| EC2 | インスタンス | jawsug-bgnr-handson-ec2 |
Amazon EC2
デプロイされた EC2 インスタンスを見ていきましょう。
東京リージョンの EC2 コンソールのインスタンスページ を開いてください。
詳細タブを確認していきます。
EC2 インスタンスは、t4g.nano インスタンスファミリー にて起動しています。
T4g インスタンスは、Graviton2 という arm インスタンスで、従来の x86_64 アーキテクチャではない、arm アーキテクチャのインスタンスで低コストでご利用いただけます。
OS は 2023 年 3 月に GA した Amazon Linux 2023 を採用しています。
Amazon Linux、Amazon Linux 2 に続く、3 世代目の Amazon 製 Fedra ベースの OS です。
[セキュリティ] タブを確認していきます。
インバウンドルールは何もルールが設定されていません。
つまり、このインスタンスに接続されたネットワークインターフェースは、受信するパケットをすべて遮断する。というかなり強力なファイアウォールが設定されている状態です。
通常、SSH 接続する場合は、22 番ポートを、Windows サーバーで Remote Desktop 接続する場合は、3389 ポートをそれぞれ開放して通信できるようにしますが、このインスタンスは受信ができない状態です。
また、アウトバウンドポートも 443 ポートのみとなっており、HTTPS で送信することしかできません。
上記のような非常に限定された状況でも、セッションマネージャーを経由してインスタンスに接続ができます。
以下の二つの機能を利用することで実現しています。
- 「戻りの通信は許可する」 というセキュリティグループのステートフル機能
- SSM Agent から SSM API に対してパケットを送信
IAM インスタンスプロフィールロールをアタッチ
- 先の手順で作成した IAM インスタンスプロフィールロールを EC2 インスタンスにアタッチします。
[アクション] ボタンから、[セキュリティ] > [IAM ロールを変更] ボタンをクリックします。
- 先ほど作成した
AmazonSSMManagedInstanceCoreEC2InstanceRoleを選択して、[IAM ロールの更新] ボタンをクリックします。
- すぐに接続できない方は、再起動をお試しください。
インスタンスを再起動すると、SSM Agent が再起動されて、すぐにセッションマネージャーが接続できるようになります。
[インスタンスの状態] をクリックして、[インスタンスを再起動] を選択。
- 確認メッセージが表示されるので、[再起動] ボタンをクリックします。
- 30 秒から 1 分程度待機します。
インスタンスを選択して、[接続] ボタンをクリックします。
- オレンジの [接続] ボタンをクリックします。
以上が、セッションマネージャーの繋ぎ方でした。
ファイルを保存する
セッションマネージャーに接続すると、以下のプロンプトが表示されるので、
sh-5.2$
SSM Agent のバージョンを確認してみましょう。
- 以下のコマンドを投入してください。
amazon-ssm-agent --version
-
プロンプトには、
SSM Agent version: 3.1.1927.0が表示されるかと思います。
エージェントのバージョンが 3.2.582.0 以上でないとロールレスで接続できません。 -
以下のコマンドを投入してください。
root ユーザーになります。
sudo -i
-
プロンプトは、
ユーザー名@ホスト名という形で表示されます。
以下の例だと、ip-10-0-1-28 というホスト名のインスタンスに root ユーザーで接続していることが分かります。
なお、ホスト名はプライベート IP アドレスを元に設定されます。プライベート IP アドレスはインスタンスページにて確認できます。
-
以下のコマンドを投入してください。
ec2-user になります。
su - ec2-user
-
以下のコマンドを投入してください。
pwdコマンドはカレントディレクトリ (現在のパス) を確認するコマンドです。
pwd
- 以下のような応答が返ります。
現在、homeディレクトリ直下のec2-userというディレクトリにいることがわかります。
[ec2-user@ip-10-0-1-28 ~]$ pwd
/home/ec2-user
[ec2-user@ip-10-0-1-28 ~]$
- ファイルを作ります。
以下のコマンドを投入してください。
touch we-love-jawsug.txt
- ファイルができましたので、
lsコマンドで確認します。
以下のコマンドを投入してください。
ls
- 「we-love-jawsug.txt」 ファイルを確認してください。
[ec2-user@ip-10-0-1-28 ~]$ ls
we-love-jawsug.txt
[ec2-user@ip-10-0-1-28 ~]$
- 以下を 3 回入力すると、セッションが切れます。
exit
- 以下の画面が表示されるので、閉じるをクリックします。
フリートマネージャー
東京リージョンのフリートマネージャー にアクセスします。
セッションマネージャーが接続できる状態ですと、インスタンスがノード一覧に表示されるはずです。
- インスタンス ID をクリックして、詳細画面に移動します。
- 左側のナビゲーションペインにある [ファイルシステム] を選択すると、ディレクトリ一覧が表示されます。
先ほど作成したファイルを探してみましょう。
-
homeディレクトリをクリックし、
-
ec2-userをクリックします。
- 先ほど作成したファイルが見れます。
- KMS 暗号化を有効化すると、アクションからファイルをプレビューしたりできます。
ディレクトリ作成などは行えます。
- 左側のナビゲーションペインにある [ユーザーとグループ] をクリックしてください。
画面遷移したら、ユーザータブとグループタブから、ユーザーとグループの一覧が確認できます。
Run Command
Run Command を利用すると、EC2 インスタンスにコマンドを投入することができます。
コマンドは SSM Agent の root 特権で実行されるため、アプリケーションのインストールなどに最適です。
一方で、git コマンドをユーザー権限で利用しているケースなどは、su コマンドでユーザーを切り替えるなどの工夫が必要です。
本手順では、Apache をインストールして Web サーバーにしてみます。
- フリートマネージャーのページが表示されている場合は、[ノードアクション] ボタンから、[run コマンドを実行] を選択してください。(4 の手順までスキップしてください。)
- フリートマネージャーの画面を閉じた方は、直接、東京リージョンの RunCommand のページにアクセスして、
- [Run Command] ボタンをクリックします。
- フィルターに、
AWS-RunShellScriptを入力して ENTER キーを押下し、[○ AWS-RunShellScript] を選択します。
- コマンドのパラメータに以下を入力します。
dnf install -y httpd
systemctl start httpd
systemctl status httpd
systemctl enable httpd
systemctl is-enabled httpd
以下のスクリーンショットのような感じです。
- ターゲットが選択されていることを確認します。[インスタンスタグの指定] を選択すると、同じタグが設定されたインスタンス全台にコマンドを送信することができます。50 台でも、100 台でも一気に処理ができます。
- ページ下部の [実行] ボタンをクリックします。
- 進行中のステータスになります。完了まで 30 秒〜 1 分ほどかかります。
- 更新ボタンをクリックして、成功を確認します。
ブラウザからアクセス
Apache のインストールが完了したので、外部から Web アクセスしてみましょう。
CloudFormation でデプロイされた EC2 インスタンスはインバウンドのセキュリティグループが開放されていないため、外からアクセスができません。
そのため、80 ポートを開放して接続できる状態にします。
- 再び EC2 コンソールのインスタンスページを開きます。セキュリティタブを開きます。
- 表示されているセキュリティグループ 「jawsug-bgnr-handson-sg-web」 をクリックして開きます。
- [インバウンドのルールを修正] ボタンをクリックします。
- [ルールの追加] ボタンをクリックして、タイプ 「HTTP」 ソース 「マイ IP」 を選択して、[ルールを保存] ボタンをクリックします。
- インスタンスページの詳細にある パブリック IPv4 アドレス をコピーして、ブラウザのアドレスバーに入力して開きます。
- ページが表示されることを確認します。
- Systems Manager の Output セクションを確認してみましょう。
コマンド結果画面から、インスタンス ID をクリックします。
- コマンドの説明とステータスの画面に遷移するので、Output を展開してください。実行されたコマンド結果が確認できます。結果が長くなると、全部が表示されないため、Amazon S3 か CloudWatch Logs に出力設定して確認する必要があります。
パッチマネージャー
最後は、パッチマネージャーの操作方法を学びます。
パッチマネージャーは、インスタンスをスキャンして、欠落しているパッチのレポートを表示したり、欠落しているすべてのパッチを自動的にインストールするなどもできる高機能なサービスです。
システムには常に脆弱性やセキュリティの問題が存在します。パッチやバージョンアップは、これらの問題を修正するためにリリースされます。セキュリティパッチを適用することで、悪意のあるハッカーやマルウェアからシステムを保護することができます。
適切なメンテナンスとアップデートを行うことで、システムは安全で効率的な状態を保つことができますが、仕様変更により誤作動が起こる可能性もあります。そのため、リリース後数日後にパッチを自動適用するだとか、検証を行った後に適用するなどの、文字通りパッチをマネジメントすることができます。
今回利用する Linux のパッチングに関しては無償で利用できます。
どのようにパッチを適用 (スキャンのみも可能) するか？を指定するためのパッチポリシーを作成します。
- 東京リージョンのパッチマネージャー にアクセスします。
- 初めてパッチマネージャーにアクセスした場合は、ウェルカムメッセージが表示されているかと思います。[パッチポリシーを作成] ボタンをクリックします。過去にアクセスしたことがある方は、 パッチ適用 まで手順をスキップしてください。
- すると、AWS Quick Setup ページが表示されますので、[使用開始] ボタンをクリックします。この Quick Setup を進めると、CloudFormation が自動的に流れて、セットアップされます。
パッチポリシーの作成
- [パッチポリシーを作成] ボタンをクリックします。設定名に任意のポリシー名を指定します。ここでは、
jawsug-bgnr-handson-pach-policyとします。
-
スキャンとインストール
スキャンのみで良い場合は、[○ スキャン] を選択します。インストールまで行う場合は、[○ スキャンとインストール] を選択します。ここでは、[○ スキャン] を選択します。
パッチベースラインについて
パッチベースラインとは、パッチのリリースから何日後にパッチを自動適用するか？といったルールと、適用承認および拒否されたパッチのリストなどを管理するための機能です。
ここでは、[推奨される既定値を使用] を選択して進めますが、
規定値の中には Amazon Linux 2023 の設定も含まれています。
設定を続けていきます。
-
ログストレージにパッチ適用
今回はハンズオンのため、ログの書き込みは行いません。チェックボックスのチェックを外してください。
-
ターゲット
AWS Organizations 配下のアカウントと単独アカウントと表示が異なりますので画面を確認しながら手順を進めてください。
- [現在のリージョン] を選択して、[手動] を選択して、インスタンスを指定してください。
- [このオプションを有効にすると、デフォルトの動作が変更されます] がインフォメーションされるので、チェックボックスにチェックを入れて、[作成] ボタンをクリックします。
- 画面遷移して、[Patch Manager Quick Setup を更新しています。] プログレスバーが表示されるので、完了を待ちます。
- Quick Setup が完了すると、緑のバーで通知されます。
- 初めてデプロイした方は、失敗が 1 件発生しているかも知れません。これは、再スキャンすると解消すると思われます。
パッチ適用
過去にパッチマネージャーを設定したことがあるアカウントだと、ひとつ上のスクリーンショットが表示されているかと思いますので、この手順から進めてください。
パッチ適用をしてみましょう。最新の AMI を使用しているので、適用する対象は表示されないと思いますが。
- パッチマネージャー にアクセスします。
- [今すぐパッチ適用] ボタンをクリックします。
- [○ 指定したターゲットインスタンスにのみパッチを適用する] を選択し、「jawsug-bgnr-handson-ec2」のチェックボックスにチェックを入れます。
- [ログストレージのパッチ適用中] の項目にて、[ログを保存しません] を選択して、[今すぐパッチ適用] ボタンをクリックします。
- スキャンの完了を待ちます。
- 完了しました。
パッチベースライン
パッチベースラインについておさらいします。
[コンプライアンスレポート] のタブを選択し、右端にある [使用されたベースライン ID] のリンクを開きます。
オペレーティングシステムが Amazon Linux 2023 になっています。承認ルールで、パッチがリリースされてから何日経過したら適用するか？といったルールを確認することができます。
以上です。お疲れ様でした。
削除手順
パッチマネージャーの設定削除
-
高速セットアップ を開きます。[○ Patch Manager] を選択し、[アクション] から [設定を削除] を選択します。
- [リージョン] のカラムが、「リージョンなし」 に変わるので、再度設定を削除します。
- 確認メッセージが表示されるので、テキストボックスに「削除」と入力して、[削除] ボタンをクリックします。
CloudFormation スタックの削除
- CloudFormation コンソールにアクセスし、スタック 「vpc-and-ec2」 を選択して [削除] ボタンをクリックします。
- スタックを削除しますか？ の確認メッセージが表示されますので、[削除] ボタンをクリックしてください。
IAM ロールの削除
- IAM ロールにアクセスして、
AmazonSSMManagedInstanceCoreEC2InstanceRoleで検索します。表示されたロールのチェックボックスにチェックを入れて、[削除] ボタンをクリックします。 - 確認メッセージが表示されるので、[削除] ボタンをクリックします。
付録： DHMC 設定
Systems Manager を利用するには、IAM ロールをアタッチする必要がありましたが、2023/02/17 に DHMC という AWS Systems Manager をアカウント内すべての EC2 インスタンスにおいてデフォルトで有効にする新機能が登場しました。
本日は DHMC 機能を使った接続方法をご紹介しますが、反映に時間がかかるのと、SSM Agent のバージョンが 3.2.582.0 以上でないとロールレス接続できないので、この手順は付録としてご紹介のみとさせていただきます。
お時間がある方は、DHMC もお試しください。
-
IAM ロールの管理ページ にアクセスします。
-
IAM ロールを作成ボタンをクリックします。
-
信頼されたエンティティを選択 画面で、EC2 を選択し、[次へ] ボタンをクリックします。
-
AmazonSSMManagedInstanceCoreを検索して、チェックボックスにチェックを入れます。[次へ] ボタンをクリックします。
-
任意の名前をつけます。ここではドキュメントに合わせて
AWSSystemsManagerDefaultEC2InstanceManagementRoleとします。
-
ページ下部の [ロールの作成] ボタンをクリックします。
-
このロールを、以下の手順で EC2 ではなく Systems Manager が利用できるようにします。
作成したロールをクリックして開きます。 -
信頼関係タブに移動します。[信頼ポリシーを編集] ボタンをクリックします。
-
ec2.amazonaws.comをssm.amazonaws.comに変更します。[ポリシーの更新] ボタンをクリックします。
-
以下のような記述になっておれば OK です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
- これで、DHMC を利用するための IAM ロールができました。
フリートマネージャーでデフォルトの設定を有効にします。 - フリートマネージャーの管理ページ にアクセスします。
- [アカウント管理] ボタンをクリックして、[デフォルトのホスト管理設定の構成] を選択します。
- [デフォルトのホスト管理設定を有効にする] のトグルボタンをクリックして有効化します。IAM ロールは、先ほど作成したロールを指定します。[設定]ボタンをクリックします。
DHMC はすぐに反映がされません。また、バージョン 3.2.582.0 以上の SSM Agent がインストールされている必要があります。
そのため、本日は従来の手順で接続します。
クレジット
（敬称略）
- 本手順の作成者
- 尾谷紘平
- ドライラン、レビュー
- 藤川源 (フォージビジョン株式会社)
- 織田繁 （株式会社ＮＳＤ @OutputSeq）
- 小林未来
- 村田真琴 （Mash&Room 味付け師 キノコ1号）
Discussion