0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

自宅のUbuntu LinuxをAWS SSMでマネージドインスタンス化

Last updated at Posted at 2024-12-07

はじめに

これまで筆者のAWS環境では、EC2インスタンスはAWS SSM(Systems Manager)でマネージドインスタンスとして管理していました。今回、初めてEC2インスタンス以外のLinux環境をAWS SSMのマネージドインスタンス化してみました。本記事では、その設定手順を備忘録として纏めます。

マネージドインスタンス化

構成図

下記のようなシンプルな構成です。
SSM構成図1.png
AWSの東京リージョンにあるSSMから、自宅で使用しているLinux環境を管理できるようにします。
マネージドインスタンス化する対象のLinuxは、Ubuntu Linux 24.04.1 LTS(※)になります。
※Windows11 PCに仮想化ソフトウェアVMWare Workstation Proを導入し、その中のゲストOSとしてLinuxを稼働させています。

設定手順

下記のAWS SSMのドキュメントの記載に沿って実施していきます。

ロールの作成

AWSのマネージメントコンソール上で、「IAM」→「ロール」と遷移し、新規のロールを作成します。このロールは後々マネージドインスタンス化する対象のLinuxにインストールします。

p24_1.jpg
信頼されたエンティティタイプに「AWSのサービス」を選択し、下にスクロールします。

p24_2.jpg

EC2インスタンスをマネージドインスタンス化する場合と違い、サービスまたはユースケースの所はプルダウンメニューから「Systems Manager」を選択します。ユースケースはシンプルに「Systems Manager」を選択して、「次へ」を押下します。

p24_3.jpg

許可ポリシーの検索画面で「AmazonSSMManagedInstanceCore」を入力してサーチし、当該ポリシーにチェックを入れます。最低限必要な許可ポリシーはこれのみですが、後々CloudWatchで監視できるように「CloudWatchAgentServerPolicy」もサーチして、当該ポリシーにチェックを入れた上で、右下の「次へ」を押下します。

p24_4.jpg

ロール名はリージョン内でユニークなネーミングであれば任意で構いません。今回は「SSMManagedServerRole」という名前を入力し、下にスクロールしてステップ1とステップ2の内容を確認し、右下の「ロールの作成」ボタンを押下します。

p24_5.jpg

ノード登録のためのハイブリッドアクティベーションの作成

AWSマネージドコンソールから「Systems Manager」→「ハイブリッドアクティベーション」と遷移し、画面右上にある「アクティベーションを作成する」を押下します。
p21.jpg
「アクティベーションの説明」箇所には任意の記述を行い、「インスタンス制限」の箇所にはAWSにマネージドインスタンスとして登録したい外部サーバーの数を指定します。1000個以上のサーバー数を登録する場合には「アドバンスインスタンス」と呼ばれる設定をする必要がありますが、今回は1個追加するだけなので、「インスタンス制限」数に1を指定します。
p22_1.jpg
IAMロールには、「必要な許可を持つ既存のカスタムIAMロールを選択する」のラジオボタンをクリックし、プルダウンメニューから、先の手順で作成した「SSMManagedServerRole」ロールを選択します。「アクティベーションの有効期限」には30日以内の日付を指定します。この期限を過ぎた後に新しいサーバーを追加したい場合には、別途新規のアクティベーションを作成する必要があります。オプションにはなっていますが、「デフォルトのインスタンス名」の箇所にもわかりやすい記述を行い、画面右下の「アクティベーションの作成」を押下します。
p22_2.jpg
アクティベーションの作成が完了すると、「Activation Code」と「Activation ID」の2つが表示されます。これは一度しか表示されないので、別途ローカルのメモ帳にメモっておきます。

Linux環境へのSSMエージェントのインストール

下記ドキュメントに記載の「Ubuntu」のコマンドをメモ帳にコピーします。

mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"

「region」にはSSMが存在するリージョン名に置き換えます。今回は東京リージョンを使用していますので、ap-northeast-1に置き換えます。"activation-code"と"activation-id"には、先の手順でメモしておいたActivateion CodeとActivation ID値に置き換えます。以下はコマンドのサンプルです。

mkdir /tmp/ssm
curl https://amazon-ssm-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "qx8lTrFSA7kHekedZt9Z" -activation-id "65c7e7e5-bb60-41ae-ae2e-173503b28fc7" -region "ap-northeast-1"

ドキュメントにも記載されていますが、「region」は"region"だけでなく、amazon-ssm-region.s3.regionの赤字部分も置き換える必要がある点にご注意ください。

置き換え後のコマンドをLinux環境で実行します。

root@Ubuntu-Server:~# mkdir /tmp/ssm
root@Ubuntu-Server:~# curl https://amazon-ssm-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 13.7M  100 13.7M    0     0  15.7M      0 --:--:-- --:--:-- --:--:-- 15.7M
root@Ubuntu-Server:~# chmod +x /tmp/ssm/ssm-setup-cli
root@Ubuntu-Server:~# /tmp/ssm/ssm-setup-cli -register -activation-code "qx8lTrFSA7kHekedZt9Z" -activation-id "65c7e7e5-bb60-41ae-ae2e-173503b28fc7" -region "ap-northeast-1"
2024-12-05 18:36:18 INFO ssm-setup-cli -version: 3.3.1345.0
2024-12-05 18:36:18 INFO Setting proxy config
2024-12-05 18:36:18 INFO Proxy environment variables:
2024-12-05 18:36:18 INFO http_proxy:
2024-12-05 18:36:18 INFO no_proxy:
:
:
(略)
:
:
2024-12-05 18:36:21 INFO Successfully downloaded agent artifacts for version: stable
2024-12-05 18:36:21 INFO Attempting to configure agent
2024-12-05 18:36:21 INFO Agent is configured successfully
2024-12-05 18:36:21 INFO Starting agent installation
2024-12-05 18:36:32 INFO Agent installed successfully
2024-12-05 18:36:32 INFO Verifying agent is installed before attempting to register
2024-12-05 18:36:32 INFO Verified agent is installed
2024-12-05 18:36:32 INFO Agent is not registered
2024-12-05 18:36:32 INFO Stopping agent before registering
2024-12-05 18:36:32 INFO Stopping agent using SnapSystemctl service manager
2024-12-05 18:36:32 INFO Successfully stopped agent
2024-12-05 18:36:32 INFO Registering agent
2024-12-05 18:36:33 INFO Successfully registered the agent, starting agent
2024-12-05 18:36:33 INFO Starting agent using SnapSystemctl service manager
2024-12-05 18:36:33 INFO Agent is running
2024-12-05 18:36:33 INFO Successfully started agent, reloading registration info
2024-12-05 18:36:33 INFO Successfully registered the instance with AWS SSM using Managed instance-id: mi-06badefa13fef0a2f
2024-12-05 18:36:38 INFO Process Path: /snap/amazon-ssm-agent/8660/amazon-ssm-agent
2024-12-05 18:36:38 INFO Agent process count: 1
2024-12-05 18:36:38 INFO Agent registration completed
root@Ubuntu-Server:~#

LinuxがマネージドインスタンスIDを付与された後、SSMエージェントが正常に登録され、Linux上でエージェントが稼働していることがわかります。

EC2インスタンスの場合はIDが「i-xxxxxx」となりますが、SSMに登録した外部サーバーの場合は「mi-xxxxx」というIDになります。

AWSマネージドコンソールで「Systems Manager」→「フリートマネージャー」に遷移すると、マネージドノードとして登録されていることが確認できます。
p23_1.jpg
赤枠のノードIDをクリックすると、下記のような詳細情報を確認できます。
p23_2.jpg
コンピュータ名の所には、登録したLinuxホスト名(Ubuntu-Server)が表示されています。IPアドレスの所に表示されているIPアドレスは、Linux上で「ip a show」コマンドの出力結果に表示されている下記のアドレスに対応しています。

root@Ubuntu-Server:~# ip a show
:
(略)
:
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:c6:93:17 brd ff:ff:ff:ff:ff:ff
    altname enp2s1
    inet 192.168.235.130/24 brd 192.168.235.255 scope global dynamic noprefixroute ens33
       valid_lft 1594sec preferred_lft 1594sec
    inet6 fe80::4c28:a3ff:1923:89c1/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
:
:

おわりに

今回は、初めてEC2インスタンス以外のサーバーをAWSのSSMでマネージドインスタンスとして管理できるようにするための設定を実施しました。EC2以外のサーバーもSSMで一元管理できるようになるとパッチのレベルなどを合せることができるようになり利便性が増えることと思います。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?