[AWS Systems Manager] アクティベーションの終わったRaspberryPiのイメージをコピーして、複数起動した時の挙動を確認してみました

2020.08.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

1 はじめに

CX事業本部の平内(SIN)です。

Amazon Systems Managerで、「遠隔地のRaspberryPiを管理すると便利」と言うことで、今回は、アクティベーションが終わったイメージを複製して、同じイメージで複数起動すると、どのような挙動となるかを確認してみました。

長くなりますので、最初に試してみた結果です。

  1. 起動後、接続可能になるまでの時間
    • 電源ONで起動した場合、約5分後に接続される
    • リブートの場合、直ちに、接続される
  2. アクティベーションが済んだイメージを複製
    • 1台だけ起動する場合、どちらでも接続可能
    • 複数台起動した場合、後から起動したものが接続される
    • 複数台起動した場合、リブートすると、どちらに接続されるかは不定
    • 複数台起動した場合、セッションマネージャから再アクティベートすると別のインスタンスとして管理される

※ あくまで、手元で試した結果です。

2 環境

RaspberryPiは、Model 3B

OSは、今年8月の最新版(Raspberry Pi OS (32-bit) Lite) 2020-08-20-raspios-buster-armhf-lite.img を使用しました。

$ cat /proc/cpuinfo  | grep Revision
Revision    : a22082

$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:    10
Codename:   buster

$ uname -a
Linux raspberrypi 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv7l GNU/Linux

3 テストの準備

(1) 1台目アクティベーション

1台目として用意したRaspberryPiは、DHCPで192.168.0.124が割り振られました。

アクティベーションを作成し、このRasberryPiでアクティベートしました。


参考:Step 5: Install SSM エージェント for a hybrid environment (Linux)

mkdir /tmp/ssm
sudo curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_arm/amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb
sudo service amazon-ssm-agent stop
sudo amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region" 
sudo service amazon-ssm-agent start

起動時に自動的に上がるように /etc/rc.local に起動コマンドを入れました。

#!/bin/sh -e
#
# rc.local
#
# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

sudo service amazon-ssm-agent start

exit 0

下記は、再起動して、セッションマネージャーから接続して、IPアドレスを確認している様子です。

(2) 複製

アクティベーションの終わったイメージを複製します。複製に使用したのは、昨日作成したバックアッププログラムです。

(3) 2台目起動

複製したイメージで、2台目のRasPiを起動しました。

コンソールで確認した所、192.168.0.123が割り振られていました。

しばらく(5分以上)してから、コンソールを確認すると、インスタンスのIPアドレスは、192.168.0.123に変わっており、セッションマネージャでの接続も、後から起動したものに接続されるようになりました。

4 オフラインから

後から起動したものが、優先して接続されることを確認するため、両方の電源を断とし、一旦、オフラインとなるようにしました。

今回は、先程と逆に、192.168.0.123の方から順に起動してみます。

  • 192.168.0.123を起動
  • 1分後に、192.168.0.124を起動

そうすると、最初に起動した時間から、約5分後に192.168.0.123に接続されました。

そして、その1分後、に192.168.0.124に接続が変わりました。

やはり、後から起動すると、それが接続されるようです。

5 電源断

2台とも起動していて、192.168.0.124に接続されている場合、これを電源断すると、直ちに、もう一台に接続可能になりました。

shutdownを入力したセッションは、その時点で利用不能となりますが、もう一度セッションを開始すると、192.168.0.123に接続できました。

6 リブート

2台が起動している状態で、接続中の端末を再起動すると、その動作は、一定ではありませんでした。

(1) パターン1

  • 124に接続中
  • 124をリブート
  • 再起動するまでの間、123に接続
  • 再起動後 124に接続が復帰する

(2) パターン2

  • 123に接続中
  • 123をリブート
  • 再起動するまでの間、124に接続
  • 123が再起動後も124に接続(123には、接続できなくなった)

7 再アクティベート

以前、確認したとおり、SSM経由でも再アクティベートは可能です。
参考:[AWS Systems Manager] SSM経由のsshで再度アクティベーションするとどうなるのか試してみました

2台が起動している状態で、再アクティベートを行うと、直ちに2つのインスタンスが管理下となりました。

8 最後に

今回は、アクティベーションの済んだRasberryPiイメージを複製して、複数起動し、その挙動を確認してみました。

挙動を上手く捉えれば、アクティベーションの済んだイメージを複製配布して、起動後に、セッションマネージャーからアクティベーションし直して、全てを別インスタンスとして管理状態にできそうです。