電子の密林を開拓する

2013年02月

今回は コマンドライン(CUI)で、ELB(ロードバランサー)を設定してみます。

手順としては以下の通り。
  • WEB用のセキュリティグループを作成
  • テンプレートとなるWEBサーバを作成
  • WEBサーバの中身を設定
  • テンプレートWEBサーバからSnapshotを作成
  • SnapshotからAMI(AmazonMachineImage)を作成
  • 不要になった テンプレート用WEBサーバを削除
  • AMIから複数台のWEBサーバを作成
  • ELBを設定し、WEBサーバを配下に加える
  • AMIから複数台のWEBサーバを作成 
  • ELBを設定し、WEBサーバを配下に加える
  • ELBの動作確認
  • ELBの削除
  • 後始末
それではやってみましょう。

前準備の手順なんて見たくない人は テキトーに読み飛ばして、ELB関連のコマンド部分だけ確認ください。


 
・セキュリティグループを作る
WEBという名前のセキュリティグループを作成し、外部から port80とport22へのアクセスを許可します。既に、相当するセキュリティグループがある場合は、ソチラを利用してもらっても構いません。
$ ec2-add-group \
     web \
     --description 'web server'

GROUP   sg-33bace32     web     web server

$ ec2-authorize \
     web \
     --protocol tcp \
     --port-range 80-80 \
     --cidr '0.0.0.0/0'

GROUP                   web
PERMISSION              web     ALLOWS  tcp     80      80      FROM    CIDR    0.0.0.0/0     ingress

$ ec2-authorize \
     web \
     --protocol tcp \
     --port-range 22-22 \
     --cidr '0.0.0.0/0'

GROUP                   web
PERMISSION              web     ALLOWS  tcp     22      22      FROM    CIDR    0.0.0.0/0     ingress
port22 の設定の際 cidr 指定で「AWS内部からだけ」というのが設定出来ればよいのですが…。やり方が良く分かりません...。まぁ、そのように設定したとしても、他人が作成したAWSインスタンスからアクセスできてしまうわけですが…。


・テンプレートとなるEC2インスタンス作成
ここでは、 innerkey という鍵ペアが存在することを前提としています。もし存在しないようなら ec2-add-keypair コマンドで作成するか、別の鍵ペアを使用してください。

作成するEC2インスタンスは、ami-20ad1221 (UbuntuOS) で、32bit マイクロ としておきます。テンプレートはAMI作成後に すぐ破棄してしまうので、TerminationProtection は利用しません。
$ ec2-run-instances \
     ami-20ad1221 \
     --group web \
     --key innerkey \
     --instance-count 1 \
     --instance-type t1.micro \
     --availability-zone ap-northeast-1a \
     --instance-initiated-shutdown-behavior stop

RESERVATION     r-31e56b32      488224276535    web
INSTANCE        i-11b39412      ami-20ad1221                    pending innerkey        0             t1.micro        2013-02-07T12:20:40+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled                                     ebs                                   paravirtual     xen             sg-33bace32     default false

$ ec2-describe-instances i-11b39412
RESERVATION     r-31e56b32      488224276535    web
INSTANCE        i-11b39412      ami-20ad1221    ec2-46-51-232-99.ap-northeast-1.compute.amazonaws.com ip-10-132-100-230.ap-northeast-1.compute.internal       pending innerkey        0             t1.micro        2013-02-07T12:20:40+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled     46.51.232.99    10.132.100.230                  ebs                                   paravirtual     xen             sg-33bace32     default false
BLOCKDEVICE     /dev/sda1       vol-4245c660    2013-02-07T12:20:43.000Z        true

$ ec2-describe-instance-status i-11b39412
     ※未だec2-run-instancesによるECインスンタンス起動処理前なので、応答が無い

$ ec2-describe-instance-status i-11b39412
INSTANCE        i-11b39412      ap-northeast-1a running 16      initializing    initializing  active
SYSTEMSTATUS    reachability    initializing
INSTANCESTATUS  reachability    initializing

$ ec2-describe-instance-status i-11b39412
INSTANCE        i-11b39412      ap-northeast-1a running 16      ok      ok      active
SYSTEMSTATUS    reachability    passed
INSTANCESTATUS  reachability    passed


・WEBサーバの中身を設定
作成した Ubuntu な EC2インスタンスにssh接続します。
$ ssh \
     -i ~/.ssh/innerkey.pem \
     -l ubuntu \
     ec2-46-51-232-99.ap-northeast-1.compute.amazonaws.com

Ubuntu 側は「WEBサーバ」となるので、Apache2 + php5 をインストールします。念のため、最初に パッケージのアップデートも実施しておきます。
ubuntu$ sudo apt-get update
ubuntu$ sudo apt-get install apache2
ubuntu$ sudo apt-get install libapache2-mod-php5
設定出来たら、apacheが動作しているかどうか確認してみます。
ubuntu$ curl 'http://localhost/'
<html><body><h1>It works!</h1>
<p>This is the default web page for this server.</p>
<p>The web server software is running but no content has been added, yet.</p>
</body></html>
WEBサーバとしての動作が確認できたら、簡単なコンテンツプログラム(php)を配備します。/var/www/ec2meta.php に以下のようなファイルを作成します。vi で作成するなら、sudo vi /var/www/ec2meta.phpですね…。
<?php
  $url = 'http://169.254.169.254';
  $data = array(
      'pattern' => 'htmlspe',
      'show' => 'quickref',
  );
  $options = array(
    'http' => array( 'method' => 'POST', 'content' => http_build_query($data) )
  );

  $pathinfo = $_SERVER['PATH_INFO'];
  if (!empty($pathinfo)) { $url .= $pathinfo; }
 
  $contents = file_get_contents( $url, false, stream_context_create( $options ) );

  if ($contents !== FALSE) { echo $contents; }
  else                     { header( 'HTTP/1.0 502 http://169.254.169.254/ does not respond.' ); }

// END of PHP //
ファイルを配備したら、動作確認してみます。
ubuntu$ curl 'http://localhost/ec2meta.php' ; echo -en "\n"
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
latest
日付が並んだ後に latest が表示されればOKです。

後で必要になるので、ここで kernel-d を取得しておきます。
$ curl 'http://localhost/ec2meta.php/latest/meta-data/kernel-id' ; echo -en "\n"
aki-ec5df7ed
AWSコマンドラインプログラムがインストールされているなら、curl コマンドを使わないで 「ec2-metadata --kernel-id」というコマンドを使ってもOKです。

最後に、Ubuntu 側から exit しておきます。
ubuntu$ exit
 
・テンプレートWEBサーバからSnapshotを作成
念のため、テンプレートWEBサーバであるEC2インスタンスを停止しておきます。
$ ec2-stop-instances i-11b39412
INSTANCE        i-11b39412      running stopping

$ ec2-describe-instance-status \
     --include-all-instances \
     i-11b39412

INSTANCE        i-11b39412      ap-northeast-1a stopped 80      not-applicable  not-applicable        active
EC2の停止を確認したら、EBSからスナップショットをとります。
$ ec2-create-snapshot \
     vol-4245c660 \
     --description 'template web Ubuntu'

SNAPSHOT        snap-c2a043e1   vol-4245c660    pending 2013-02-07T12:44:43+0000              488224276535    8       template web Ubuntu

$ ec2-describe-snapshots
SNAPSHOT        snap-c2a043e1   vol-4245c660    pending 2013-02-07T12:44:43+0000              488224276535    8       template web Ubuntu

$ ec2-describe-snapshots snap-c2a043e1
SNAPSHOT        snap-c2a043e1   vol-4245c660    completed       2013-02-07T12:44:43+0000      100%    488224276535    8       template web Ubuntu

$ ec2-describe-snapshots
SNAPSHOT        snap-c2a043e1   vol-4245c660    pending 2013-02-07T12:44:43+0000              488224276535    8       template web Ubuntu
パラメータ無しの ec2-describe-snapshots ダケだと pending のままですが、確認対象の snapshot-id を与えると、ちゃんと completed になります。不思議な挙動…。
ちなみに AWS Management Console だと Completed になってます……謎すぎる。
...
しばらく放置したら、ec2-describe-snapshots ダケでも completed になりました。何かキャッシュされているんでしょうかね???


・SnapshotからAMI(AmazonMachineImage)を作成
Snapshot から AMI を作成するには ec2-register コマンドを使用します。
$ ec2-register \
     --snapshot snap-c2a043e1 \
     --kernel aki-ec5df7ed \
     --name 'web_template' \
     --description 'web template Ubuntu'

IMAGE   ami-3d76f23c

$ ec2-describe-images
IMAGE   ami-3d76f23c    488224276535/web_template       488224276535    available       private               i386    machine aki-ec5df7ed                    ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-c2a043e1   8       true    standard
AMI の出来上がり。



不要になった テンプレート用WEBサーバを削除
テンプレートWEBサーバは既にSTOPさせてあるので、TERMINATE させます。
$ ec2-terminate-instances  i-11b39412
INSTANCE        i-11b39412      stopped terminated
これで、テンプレートWEBのEC2インスタンスは削除されました。
EBS Volume も同時に消されているはずですが、もし残っていたら ec2-delete-volumes で削除しておいてください。



・AMIから複数台のWEBサーバを作成
作成済みの AMI (ami-c15fdbc0) を使って、EC2インスタンスを二つ起動します。
$ ec2-run-instances \
     ami-3d76f23c  \
     --group web \
     --key innerkey \
     --instance-count 2 \
     --instance-type t1.micro \
     --availability-zone ap-northeast-1a \
     --instance-initiated-shutdown-behavior stop


RESERVATION     r-8bee6788      488224276535    web
INSTANCE        i-437a5b40      ami-3d76f23c                    pending innerkey        0             t1.micro        2013-02-08T10:29:33+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled                                     ebs                                   paravirtual     xen             sg-33bace32     default false
INSTANCE        i-417a5b42      ami-3d76f23c                    pending innerkey        1             t1.micro        2013-02-08T10:29:33+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled                                     ebs                                   paravirtual     xen             sg-33bace32     default false
実行開始コマンド入力した後、ec2-describe-instance-status で状況を確認します。
$ ec2-describe-instance-status i-437a5b40 i-417a5b42
INSTANCE        i-437a5b40      ap-northeast-1a running 16      ok      ok      active
SYSTEMSTATUS    reachability    passed
INSTANCESTATUS  reachability    passed
INSTANCE        i-417a5b42      ap-northeast-1a running 16      ok      ok      active
SYSTEMSTATUS    reachability    passed
INSTANCESTATUS  reachability    passed
kernel-id の指定が間違っていたり(あるいは指定忘れていたり)すると、status が impaired (傷んでる/壊れている...ぐらいの意味)になったり、passed にならないコトがあります。その場合は コマンドヒストリを見返す等して、再確認してみてください。



・ELBを設定し、WEBサーバを配下に加える
ELB(ロードバランサー)を作成するのは elb-create-lb というコマンドを使用します。

ちなみに、elb-* 系コマンドは 以前設定した環境変数の EC2_URL を参照してくれないので、コマンドラインで指定する必要があります。環境変数で指定したい場合は EC2_REGION 環境変数を設定しておいてください。

ここでは httpbalancer という名前の ELB を作成します。
$ elb-create-lb \
     httpbalancer \
     --scheme internet-facing \
     --region ap-northeast-1 \
     --availability-zones ap-northeast-1a \
     --listener 'protocol=HTTP, lb-port=80, instance-port=80'


DNS_NAME  httpbalancer-1887544794.ap-northeast-1.elb.amazonaws.com
(EC2_URL環境変数に頼っているつもりで) --region オプションを指定しないと、謎のエラーに悩まされるか、あるいは意図しない region にロードバランサーが作成されるので注意してください。

 次にELBのヘルスチェック(死活監視)を設定します。
$ elb-configure-healthcheck \
     httpbalancer \
     --region ap-northeast-1 \
     --target 'http:80/' \
     --interval 30 \
     --timeout 5 \
     --healthy-threshold 4 \
     --unhealthy-threshold 2

HEALTH_CHECK  http:80/  30  5  4  2
チェック間隔は30秒、2回チェック失敗でunhealthy扱い、4回チェック成功でhealthyに戻す…という設定にします。

ELBの配下に、先に用意した二台のWEBサーバ(EC2インスタンス)を加えます。
$ elb-register-instances-with-lb \
     httpbalancer \
     --region ap-northeast-1 \
     --instances  i-437a5b40,i-417a5b42

INSTANCE_ID  i-417a5b42
INSTANCE_ID  i-437a5b40
--instances オプションに与える instance-id は(コマンの前後にも)空白を含めたりせず 繋げて指定してください。そうしないと謎のエラーに悩まされます…(x_x;

次に作成されたロードバランサーの状態を確認してみます。
$ elb-describe-lbs --region ap-northeast-1

LOAD_BALANCER  httpbalancer  httpbalancer-1887544794.ap-northeast-1.elb.amazonaws.com  2013-02-08T11:07:45.180Z  internet-facing
すごく普通…。

そして、ロードバランサーの配下に組み込まれたWEBサーバの状態(と言うか、ロードバランサーがWEBサーバを死活確認しているのでその結果)を表示してみます。

$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1

INSTANCE_ID  i-417a5b42  OutOfService  Instance registration is still in progress.  ELB
INSTANCE_ID  i-437a5b40  OutOfService  Instance registration is still in progress.  ELB

※↑ELB配下へEC2を登録している最中...という意味


$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1

INSTANCE_ID  i-417a5b42  InService  N/A  N/A
INSTANCE_ID  i-437a5b40  InService  N/A  N/A

※↑ EC2のinstance-id を指定しないせず、配下のEC2インスタンスを全表示した結果。

$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1 \
     --instances i-437a5b40,i-417a5b42
INSTANCE_ID  i-437a5b40  InService  N/A  N/A
INSTANCE_ID  i-417a5b42  InService  N/A  N/A

※↑ EC2のinstance-id を指定して、2つだけ表示した結果。
二つ並んだ N/A が何を意味しているのか分かりませんが、とりあえず InService なので問題ないのでしょう。



ELBの動作確認
curlコマンドを使って、ロードバランサー経由で配下のWEBサーバにアクセスしてみます。
ロードバランサーのFQDNは elb-describe-lbs コマンドで入手したものを使用します。
$ for R in $(seq 1 10) ; do \
     curl 'http://httpbalancer-1887544794.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/instance-id/'; \
     echo -en "\n" ; \
     done

i-437a5b40
i-417a5b42
.....
i-437a5b40
i-417a5b42
交互にアクセスが分散されていますね…。

もし、アクセスが届かない場合、FQDNの先頭に ipv6. とか dualstack. とかを付けてみると良いかもしれません。前者は IPv6 のホスト名で、後者は IPv4,IPv6共用らしいです。

これで動作確認は終わり!!! (動いてることを確認しただけですが ^^;)



ELBの削除
作成したのとは逆の手順でロードバランサーを破棄します。
まず最初にロードバランサー配下からEC2インスタンスを排除し、その後、ロードバランサーであるELBを消去します。

ELBの配下からEC2を排除するには elb-deregister-instances-from-lb コマンドを使用します。とりあえず、ECを1台だけ排除してみます。
$ elb-deregister-instances-from-lb \
     httpbalancer \
     --region ap-northeast-1 \
     --instances  i-437a5b40

INSTANCE_ID  i-417a5b42

$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1 \
     --instances i-437a5b40,i-417a5b42

INSTANCE_ID  i-437a5b40  OutOfService  Instance is not currently registered with the LoadBalancer.  Instance
INSTANCE_ID  i-417a5b42  InService     N/A
指定したEC2(i-437a5b40)が排除されましたね…。残ったEC2も含めて排除してしまいましょう。
$ elb-deregister-instances-from-lb \
     httpbalancer \
     --region ap-northeast-1 \
     --instances  i-437a5b40,i-417a5b42

No instances currently registered to LoadBalancer


$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1 \
     --instances i-437a5b40,i-417a5b42

INSTANCE_ID  i-437a5b40  OutOfService  Instance is not currently registered with the LoadBalancer.  Instance
INSTANCE_ID  i-417a5b42  OutOfService  Instance is not currently registered with the LoadBalancer.  Instance


$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1
No instances currently registered to LoadBalancer

これで、ELBからEC2インスタンスがすべて排除されました。

最後に、ELB本体を削除します。
$ elb-delete-lb \
     httpbalancer \
     --region ap-northeast-1

Warning: Deleting a LoadBalancer can lead to service disruption to any
customers connected to the LoadBalancer. Are you sure you want to delete
this LoadBalancer? [Ny] y
OK-Deleting LoadBalancer

$ elb-describe-lbs --region  ap-northeast-1
elb-delete-lb  コマンドを使用すると、プロンプトが出て y か N で回答を求められます。y で削除できますが、めんどくさければ --force オプションで強制消去することもできます。

最後の elb-describe-lbs コマンドに対して、何も結果が表示されないので、ELBは消えたということになります。

これで、ELBの消去作業は終了。



後始末
不要になった AMI、Snapshot、EC2インスタンスを削除しておいてください。

AMI削除はec2-deregister、Snapshot削除は ec2-delete-snapshots、EC2インスタンス削除は ec2-stop-instances、ec2-terminate-instances です。

EC2のTerminationProtectionを使用しているなら「ec2-modify-instance-attribute INSTANCE_ID --disable-api-termination false 」で解除できます。


今回はここまで。

続きを読む

AWS公式ブログを書いている人(玉川憲氏)によると、ELBのIPアドレスは変化することがあるらしいです。

http://www.slideshare.net/AmazonWebServicesJapan/elb-cloudwatch-autoscaling-aws
ELBはトラフィックにあわせ、自動的にキャパシティを増減する
→ 数も増減するので、IPアドレスはそれに伴い変わる
    ・ (重要)ELBを使用するときには、DNS名を用いる
    ・独自ドメイン名には、名前解決にCNAMEを用いる
今まで、ELBには CNAME を利用する…と聞いていたけど、その理由が納得できた気がする。

同じ記事内で、ELB(TokyoRegion)がIPv6をサポートしていると書かれています。
今のところIPv6なんて(個人的には)使ってませんので、あくり興味は無いですが…。

どちらかと言えば、以下のような点の方が気になりますね…。

    ・EIPに IPv6 を割り当てできないのか?
         ⇒ ec2-allocate-address のオプションで、IPv6の指定は存在しないので
              たぶん無理かなー。

    ・ELBには EIPを割り当てできないのか?
          ⇒ CNAME使え…って言うぐらいだから、使えないんだろうなぁ…。
               グローバルIPを振れるなら、CNAME使う理由ないもんね…。


分からないことだらけで、もやもや中…。

公式のAWSコマンド一覧を発見…!
http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/command-reference.html


コマンドの種類ごとに分類されたリストもありますね…。
http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/OperationList-cmd.html


しかし、AmazonLinux の /opt/aws/bin/ には存在したはずの、elb-* コマンドとかの説明は見つかりませんね……。
リストを良く見てみてたら ec2-* コマンドばっかりですし(x_x;



だいたい http://aws.amazon.com/jp/documentation/ あたりからリンクされていると思うのですが…。うーむ。


現在、EC2インスタンをウマクやりくりして、無料の範囲で使用していますが…。
EC2インスタンスの課金は「時間単位」なので、意外な罠がある様子。

http://docs.aws.amazon.com/gettingstarted/latest/awsgsg-freetier/TestDriveFreeTier-monthly.html

  1. 1インスタンスを3時間継続使用する
  2. 1インスタンスを1時間の間に、3回起動し、3回終了させる

上記の手順だと、1と2 どちらの場合でも 3時間分の利用としてカウントされるそうです…。


マジですかー!?

こまめにインスタンスをON/OFFするのは、サイフに優しくないのですね…。

今回はEIPの使い方を調べてみます。
1台だけ起動している AmazonLinux な EC2インスタンスに、EIP を付与してみる実験。


・コマンドを調べる
AWSでは、固定IP取得の仕組みは ElasticIP (EIP) と呼ばれている。で、AWSコマンドには address という文字列が入るみたい。ls -1 /opt/aws/bin/ec2-*address* として、それらしいコマンドを探してみる。で、それらのコマンドに --help オプションを与えて説明を読んでみると……。
/opt/aws/bin/ec2-allocate-address
  ⇒ EIP を確保する
/opt/aws/bin/ec2-release-address
  ⇒ 確保済みのEIPを解放する
/opt/aws/bin/ec2-describe-addresses
  ⇒ 確保済みのEIPを列挙する
/opt/aws/bin/ec2-associate-address
  ⇒ 公開IPアドレスをNICに割り当てる。VPCでは使えない?
/opt/aws/bin/ec2-disassociate-address
  ⇒ インスタンス(NICの間違い?)へのEIP割り当てを解除する
/opt/aws/bin/ec2-assign-private-ip-addresses
  ⇒ セカンダリとなるプライベートIPアドレスを指定されたNICに割り当てる
/opt/aws/bin/ec2-unassign-private-ip-addresses
  ⇒ セカンダリのプライベートIPアドレスを、NICから割り当て解除する
恐らく最初の4つが期待するコマンドらしい。残り3つは VPC 環境用の プライベートIPアドレスの操作に使用するみたい。



・EIPを確保する
ec2-allocate-address コマンドを実行するだけ。
 ec2-allocate-address
ADDRESS 54.249.233.194          standard
IPv4のアドレスが割り当てられた。IPv6の割り当てはされないのかな???



・EIPをEC2インスタンスに割り当てる
ec2-describe-instances あるいは ec2-describe-instance-stats で EC2インスタンスID を確認した後、ec2-associate-address で EIP を割り当てます。
$ ec2-describe-instance-status
INSTANCE        i-0f1b440c      ap-northeast-1a running 16      ok      ok      active
SYSTEMSTATUS    reachability    passed
INSTANCESTATUS  reachability    passed

$ ec2-associate-address 54.249.233.194 --instance  i-0f1b440c
ADDRESS 54.249.233.194  i-0f1b440c
あたりまえですが、間違ったEIP(ec2-allocate-addressで確保されていないIPアドレス)を指定すると、エラーで怒られます。
$ ec2-associate-address 54.249.233.192 --instance  i-0f1b440c
Client.AuthFailure: The address '54.249.233.192' does not belong to you.
…で、EIPの割り当てに成功すると、困ったことが起こります…。なんと、それまでに使用していた PublicDNS (と IPアドレス)が失われるので ssh 接続が切断されてしまうのです。
切断と言うか「固まる」ので、どうなったのかサッパリ分からないのですが…。
たぶん、1つのEC2インスタンスには複数のグローバルIPアドレス(PublicDNS)を割り当てできないのでしょう…。これ…、自分自身のIPアドレスを付与する時、困りますよねw

気を取り直して、ssh を再接続してみます。PublicDNS (ホスト名)も変わっているので、新しいホスト名か、IPアドレスでログインします。
先ほど「固まってしまったユーザー」がログインしたままの状態で残っています。気分が悪いので reboot してしまいます(きれいに kick する方法を知らないだけ...)

$ w
 10:02:48 up  1:04,  2 users,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
ec2-user pts/0    161.90.128.210.b 09:39   10:16   0.05s  0.05s -bash
ec2-user pts/1    161.90.128.210.b 09:59    0.00s  0.01s  0.00s w

$ sudo reboot
Broadcast message from ec2-user@ip-10-150-186-177
        (/dev/pts/1) at 10:03 ...

The system is going down for reboot NOW!
Connection to ec2-54-249-233-194.ap-northeast-1.compute.amazonaws.com closed by remote host.
Connection to ec2-54-249-233-194.ap-northeast-1.compute.amazonaws.com closed.

LOCAL-PC$ ssh -i ~/.ssh/exploreaws.pem -l ec2-user ec2-54-249-233-194.ap-northeast-1.compute.amazonaws.com

Last login: Fri Feb  1 09:59:29 2013 from 161.90.128.210.bf.2iij.net

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2012.09-release-notes/
There are 3 security update(s) out of 43 total update(s) available
Run "sudo yum update" to apply all updates.

$ w
 10:04:02 up 0 min,  1 user,  load average: 0.13, 0.03, 0.01
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
ec2-user pts/0    161.90.128.210.b 10:04    0.00s  0.00s  0.00s w
キレイに消えました。



・EIP割り当て状況の確認
EIPの割り当て状況を確認してみます。ec2-describe-addresses コマンドと、ec2-describe-instances を使います。
$ ec2-describe-addresses
ADDRESS 54.249.233.194  i-0f1b440c      standard

$ ec2-describe-instances
RESERVATION     r-d9d051da      488224276535    master-controller
INSTANCE        i-0f1b440c      ami-486cd349    ec2-54-249-233-194.ap-northeast-1.compute.amazonaws.com       ip-10-150-186-177.ap-northeast-1.compute.internal       running exploreaws    0               t1.micro        2013-02-01T08:57:52+0000        ap-northeast-1a aki-42992843                  monitoring-disabled     54.249.233.194  10.150.186.177                  ebs                                   paravirtual     xen     BswvR1359633479419      sg-53255152   default false
BLOCKDEVICE     /dev/sda1       vol-6057ec42    2013-01-31T11:58:04.000Z        true
TAG     instance        i-0f1b440c      Name    MasterController
バッチリ期待通りに割り当てられていますね。



・EIPの割り当て解除と解放
念のため、EIP割り当て解除と解放も試しておきます。
割り当て解除は ec2-disassociate-address ですが……先ほどの状況から考えると、EIPの割り当て解除した瞬間に ホスト名とIPアドレスが変化してしまい、ssh接続が切断(ロック)してしまうと想定されます。
…まぁ、悩んでも仕方ないので実行してしまいます。
$ ec2-disassociate-address 54.249.233.192
ADDRESS 54.249.233.192
やはりssh接続が切断(ロック)されてしまいます。それだけでなく、PublicDNSが失われたまま、外部から再接続する方法もなくなります!(ガーン

数分(5分ぐらい?)放置すると、再度、自動的に PublicDNSが割り当てられるようです。待てないなら、AWS Management Console から EC2インスタンスを再起動すればよいかと思います。EIPではない 自動採番的なPublicDNS(というかグローバルIPアドレス)を強制再割り当てする方法があれば良いのですが...。

再度 ssh で接続しなおして、EIPの状況を確認します。
$ ec2-describe-addresses
ADDRESS 54.249.233.192           standard
当然、EIPは確保されたままなので、これを解放します。
$ ec2-release-address 54.249.233.192
ADDRESS 54.249.233.192

$ ec2-describe-addresses
EIPが解放されました。



ちなみに、ec2-disassociate-address を実行する前に(EC2インスタンスにEIPが割り当てられた状態のまま) ec2-release-address を実行することもできます(できました)。間違って解放しないように注意が必要ですね…。





・まとめ/Tip
  • ec2-associate-address でEIPを付与するのは一瞬で完了するが、ec2-disassociate-address でEIP割り当てを解除されたインスンタンに自動採番されたグローバルIPアドレスが再割り当てされるのには 数分以上の時間がかかる。
  • グローバルIPは、1つのインスタンスに1つしか割り当てできないようなので、ec2-associate-address や ec2-disassociate-address はEIPが割り当てられるサーバ以外から実行るのが望ましい。
  • EIPにはコメントも付けられないし、EC2の「TerminateProtection」のようなモノ(ReleaseProtection とか DisallocateProtection ?) も付けられない。そのため、EIPを操作する際には細心の注意が必要。



このページのトップヘ