電子の密林を開拓する

2013年01月

前回は、EBS からバックアップした EBS Snapshot を使って AMI を作成しました。
今回は、AMI ではなく、直接 EBS Volume を作成し、EC2インスタンスにマウントしてみます。


・コピー元となるEBSを持つEC2インスタンスの確認
まず、コピー元となる EC2インスタンスの instance-id を取得します。
$ curl 'http://169.254.169.254/latest/meta-data/instance-id'; echo -en "\n"
i-3b0b4738

$ ec2-describe-instances i-3b0b4738
RESERVATION     r-83af1c80      354893364746    web
INSTANCE        i-3b0b4738      ami-486cd349    ec2-54-248-161-5.ap-northeast-1.compute.amazonaws.com   ip-10-128-75-156.ap-northeast-1.compute.internal    running default 0               t1.micro        2013-01-29T11:51:35+0000    ap-northeast-1b aki-42992843                    monitoring-disabled     54.248.161.5    10.128.75.156               ebs                                     paravirtual     xen     LvWjn1358508959781      sg-c42c45c5     default false
BLOCKDEVICE     /dev/sda1       vol-765ff554    2013-01-18T11:36:03.000Z        true
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
上記結果から、以下のようになっていることが分かります。
    EC2 instance-id = i-3b0b4738
    EC2 AvailabilityZone = ap-northeast-1b
    EC2 Kernel-ID = aki-42992843  (今回は使わない値ですが)
    EBS Volume = vol-765ff554
    EBS のマウント位置 : /dev/sda1



・EBSスナップショト作成
スナップショットを作成するコマンドは ec2-create-snapshot 、スナップショットの状態を確認するコマンドは ec2-describe-snapshots です。では、実行してみましょう。
$ ec2-create-snapshot \
     --description 'Master AmazonLinux' \
     vol-765ff554

SNAPSHOT         snap-1cfff33c  vol-765ff554    pending 2013-01-29T12:02:38+0000                354893364746    8   Master AmazonLinux

$ ec2-describe-snapshots
SNAPSHOT        snap-1cfff33c   vol-765ff554    completed       2013-01-29T12:02:38+0000        100%    354893364746        8       Master AmazonLinux
今回使用しているEC2インスタンスのEBSは、デフォルトの8GBしか容量が無いので 比較的すぐに pending → completed になりますね。



・スナップショットからEBSボリューム作成
EBSボリュームを作成するのは ec2-create-volume コマンドです。アタッチするEC2インスタンスと同一 AvailavilityZone に作成する方が望ましいので、そのように指定します。
$ ec2-create-volume \
     --snapshot snap-1cfff33c \
     --availability-zone ap-northeast-1b
VOLUME  vol-59ca737b    8       snap-1cfff33c   ap-northeast-1b creating        2013-01-29T13:12:08+0000        standard

$ ec2-describe-volumes
VOLUME  vol-59ca737b    8       snap-1cfff33c   ap-northeast-1b available       2013-01-29T13:12:08+0000        standard
VOLUME  vol-765ff554    8       snap-1ee78f3f   ap-northeast-1b in-use  2013-01-18T11:36:03+0000        standard
ATTACHMENT      vol-765ff554    i-3b0b4738      /dev/sda1       attached        2013-01-18T11:36:03+0000        true
ec2-describe-volume の結果にも、新しく作成されたEBSボリュームが表示されていますね。
ちなみに、下側の vol-765ff554 は もともと存在していた(コピー元の) EBSボリュームです。




・EC2インスタンスへアタッチ
ec2-attach-volume というコマンドでアタッチ(EBSをEC2へ取り付け)するらしいけれど……。デバイス名の指定が必要らしい。空いているデバイス名を探す必要がありますね。
$ mount
/dev/xvda1 on / type ext4 (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  887M  7.0G  12% /
tmpfs                 301M     0  301M   0% /dev/shm
…わからん。
ec2-describe-instances による情報では「デフォルトのEBS は /dev/sda1 にアタッチされている」ということだったけど……。/dev/xvda1 とは何だ???

とりあえず、ec2-describe-instances の情報通り /dev/sda1 に EBSがアタッチされているのだと信じます。それに倣うのであれば、新しいEBSボリュームは /dev/sdb1 にアタッチすることになります(別に、他のデバイス名でも良いけど……/dev/sda999 とかでもOKなのかな?[謎])。
$ ec2-attach-volume vol-59ca737b --instance i-3b0b4738 --device /dev/sdb1
ATTACHMENT      vol-59ca737b    i-3b0b4738      /dev/sdb1       attaching       2013-01-29T13:33:10+0000

$ ec2-describe-instances i-3b0b4738
RESERVATION     r-83af1c80      354893364746    web
INSTANCE        i-3b0b4738      ami-486cd349    ec2-54-248-161-5.ap-northeast-1.compute.amazonaws.com   ip-10-128-75-156.ap-northeast-1.compute.internal    running default 0               t1.micro        2013-01-29T11:51:35+0000    ap-northeast-1b aki-42992843                    monitoring-disabled     54.248.161.5    10.128.75.156               ebs                                     paravirtual     xen     LvWjn1358508959781      sg-c42c45c5     default false
BLOCKDEVICE     /dev/sda1       vol-765ff554    2013-01-18T11:36:03.000Z        true
BLOCKDEVICE     /dev/sdb1       vol-59ca737b    2013-01-29T13:33:10.000Z        false
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
新しく作成したEBSボリュームをEC2インスタンスにアタッチできたみたい。
次は mount してみます。ここでは /mnt/extra というディレクトリを作成し、ソコをマウントポイントにします。
$ sudo mkdir -p /mnt/extra

$ sudo mount /dev/sdb1 /mnt/extra

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  887M  7.0G  12% /
tmpfs                 301M     0  301M   0% /dev/shm
/dev/xvdb1            7.9G  887M  7.0G  12% /mnt/extra

$ ls -lah /mnt/extra/
total 108K
dr-xr-xr-x 22 root root 4.0K Jan 29 11:52 .
drwxr-xr-x  3 root root 4.0K Jan 29 13:16 ..
-rw-r--r--  1 root root    0 Jan 29 11:52 .autofsck
dr-xr-xr-x  2 root root 4.0K Oct  8 17:10 bin
dr-xr-xr-x  3 root root 4.0K Oct  8 17:10 boot
drwxr-xr-x  2 root root 4.0K Jan  6  2012 dev
drwxr-xr-x 67 root root 4.0K Jan 29 11:52 etc
drwxr-xr-x  3 root root 4.0K Oct  8 18:10 home
dr-xr-xr-x 15 root root  12K Oct  8 18:10 lib
drwxr-xr-x  2 root root 4.0K Oct  8 17:06 local
drwx------  2 root root  16K Oct  8 17:06 lost+found
drwxr-xr-x  2 root root 4.0K Jan  6  2012 media
drwxr-xr-x  2 root root 4.0K Jan  6  2012 mnt
drwxr-xr-x  3 root root 4.0K Oct  8 17:08 opt
drwxr-xr-x  2 root root 4.0K Oct  8 17:06 proc
dr-xr-x---  3 root root 4.0K Jan 18 11:36 root
dr-xr-xr-x  2 root root 4.0K Oct  8 17:10 sbin
drwxr-xr-x  2 root root 4.0K Jan  6  2012 selinux
drwxr-xr-x  2 root root 4.0K Jan  6  2012 srv
drwxr-xr-x  2 root root 4.0K Oct  8 17:06 sys
drwxrwxrwt  5 root root 4.0K Jan 29 11:58 tmp
drwxr-xr-x 12 root root 4.0K Oct  8 17:06 usr
drwxr-xr-x 19 root root 4.0K Oct  8 17:10 var
mount できた。

/dev/sdb1 というデバイス名にしたはずが、なぜか /dev/xvdb1 という名前に変換されていますね…。EBS の仕組みせい? あるいは AmazonLinux は、そういう挙動をするのかしら? 分からない……。

とりあえず、マウント自体は出来ているのでヨシとしておきます。




・後始末
まずは unmount (=umountコマンド)から。
umount するデバイス名は… /dev/xvdb1 と /dev/sdb1 と、どちらで指定しても良いみたい。謎すぎる。ここでは /dev/sdb1 として umount しておきます。
$ sudo umount /dev/sdb1

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  887M  7.0G  12% /
tmpfs                 301M     0  301M   0% /dev/shm
次は EBS Volume のデタッチ(切り離し)。
ec2-detach-volume コマンドに EBS Volume ID だけ指定すれば良いみたい。
$ ec2-detach-volume vol-59ca737b
ATTACHMENT      vol-59ca737b    i-3b0b4738      /dev/sdb1       detaching       2013-01-29T13:33:10+0000
あるいは、間違ったVolume をdetachしてしまうトラブルを避けるなら、instance-ID と デバイス名 を両方とも指定する方が良いかも。以下、全部指定する場合の例。指定を間違えるとエラーになっているのが分かります。
$ ec2-detach-volume \
     vol-59ca737b
\
     --instance i-3b0b4738 \
     --device /dev/sdc1
Client.InvalidAttachment.NotFound: The volume 'vol-59ca737b' is not attached to instance 'i-3b0b4738' as device '/dev/sdc1'.
    ⇒ /dev/sdc1 なんて名前のデバイスは無い

$ ec2-detach-volume \
     vol-59ca737b
\
     --instance i-3b0b4738 \
     --device /dev/xvdb1
Client.InvalidAttachment.NotFound: The volume 'vol-59ca737b' is not attached to instance 'i-3b0b4738' as device '/dev/xvdb1'.
    ⇒ umount と違って /dev/xvdb1 というデバイス名では認識されない

$ ec2-detach-volume \
     vol-59ca737b \
     --instance i-3b0b4738 \
     --device /dev/sdb1
ATTACHMENT      vol-59ca737b    i-3b0b4738      /dev/sdb1       detaching       2013-01-29T13:46:10+0000

$ ec2-describe-instances i-3b0b4738
RESERVATION     r-83af1c80      354893364746    web
INSTANCE        i-3b0b4738      ami-486cd349    ec2-54-248-161-5.ap-northeast-1.compute.amazonaws.com   ip-10-128-75-156.ap-northeast-1.compute.internal    running default 0               t1.micro        2013-01-29T11:51:35+0000    ap-northeast-1b aki-42992843                    monitoring-disabled     54.248.161.5    10.128.75.156               ebs                                     paravirtual     xen     LvWjn1358508959781      sg-c42c45c5     default false
BLOCKDEVICE     /dev/sda1       vol-765ff554    2013-01-18T11:36:03.000Z        true
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
これでデタッチ(切り離し)できました。


次は、 EBS Volume の削除。ec2-delete-volume コマンドを使用します。
$ ec2-delete-volume vol-59ca737b
VOLUME  vol-59ca737b

$ ec2-describe-volumes vol-59ca737b
Client.InvalidVolume.NotFound: The volume 'vol-59ca737b' does not exist.

$ ec2-describe-volumes
VOLUME  vol-765ff554    8       snap-1ee78f3f   ap-northeast-1b in-use  2013-01-18T11:36:03+0000        standard
ATTACHMENT      vol-765ff554    i-3b0b4738      /dev/sda1       attached        2013-01-18T11:36:03+0000        true
消えました。
一個残っている EBS Volume は、起動している AamzonLinux 自身が使用しているモノですね。



残っている EBS Snapshot を確認してみます。
$ ec2-describe-snapshots
SNAPSHOT        snap-1cfff33c   vol-765ff554    completed       2013-01-29T12:02:38+0000        100%    354893364746        8       Master AmazonLinux
ところで EBS Snapshot にも VolumeID があるけど、直接 EBS として attach できるのでしょうか??? 試してみます…。
$ ec2-attach-volume vol-765ff554 --instance i-3b0b4738 --device /dev/sdc1
Client.VolumeInUse: vol-765ff554 is already attached to an instance
あら???
この VolumeID が何なのか調べてみましょう。
$ ec2-describe-volumes vol-765ff554
VOLUME  vol-765ff554    8       snap-1ee78f3f   ap-northeast-1b in-use  2013-01-18T11:36:03+0000        standard
ATTACHMENT      vol-765ff554    i-3b0b4738      /dev/sda1       attached        2013-01-18T11:36:03+0000        true
あああぁぁ…。
この VolumeID は、バックアップ取得元の EBS VolumeID ということなのですね...(つまり、最初から存在していたEBS Volume である…と)。



最後に、不要になったスナップショットを ec2-delete-snapshot コマンドで削除します。
$ ec2-delete-snapshot snap-1cfff33c
SNAPSHOT        snap-1cfff33c
$ ec2-describe-snapshots

消えました。





これで、コマンドラインから EBS ボリュームのスナップショット(バックアップ)を作成し、そこから 再度 EC2インスタンスへアタッチ可能な EBS ボリュームを作成することが出来るようになりました。



今回はここまで。








今回は、EBS (仮想化HDD)のバックアップを作成し、そこからAMI(ブートイメージ)を作成してみます。もちろん、コマンドライン(CUI)で……。


・最初のEC2インスタンス
AmazonLinux を OS として、EC2インスタンス(Micro 32bit, EBS)を起動し、その上で作業します。つまり、今回の作業は自分自身をバックアップする…ということになります。

後から必要になるので「起動したEC2インスタンス上で、自分自身の instance-idを取得」しておきます。
$ curl 'http://169.254.169.254/latest/meta-data/instance-id'; echo -en '\n'
i-3b0b4738
http://169.254.169.254/ にhttpアクセスすれば、アクセス元のEC2インスタンス情報をレスポンスとして得られます。その中に instance-id が存在するので、ソレを使うことにします。

また、同じようにしてEC2 インスタンスが使用している kernel-id も取得しておきます。
$ curl 'http://169.254.169.254/latest/meta-data/kernel-id'; echo -en '\n'
aki-42992843
kernel-id が無いと、この後 作成する AMI (AmazonMachineImage)が「正しく起動しない」ものになってしまうので…。使用しているOSやインスタンスタイプによっては、指定しなくても動作するかもしれませんが…。




・EBSのID (volume-id)を調べる
まずは、起動している AmazonLinux にマウントされている EBS の ID を調べます。
先に調べておいた EC2の instance-id をパラメータとして ec2-describe-instances コマンドを使用します。
$ ec2-describe-instances  i-3b0b4738
RESERVATION     r-83af1c80      354893364746    web
INSTANCE        i-3b0b4738      ami-486cd349    ec2-46-51-239-135.ap-northeast-1.compute.amazonaws.com  ip-10-128-75-253.ap-northeast-1.compute.internal    running default 0               t1.micro        2013-01-28T10:54:20+0000    ap-northeast-1b aki-42992843                    monitoring-disabled     46.51.239.135   10.128.75.253               ebs                                     paravirtual     xen     LvWjn1358508959781      sg-c42c45c5     default false
BLOCKDEVICE     /dev/sda1       vol-765ff554    2013-01-18T11:36:03.000Z        true
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
/dev/sda1 にマウントされているのは vol-765ff554 という EBS になっているようです。

では、次に、EBS の状態を見てみましょう。
$ ec2-describe-volumes vol-765ff554
VOLUME  vol-765ff554    8       snap-1ee78f3f   ap-northeast-1b in-use  2013-01-18T11:36:03+0000        standard
ATTACHMENT      vol-765ff554    i-3b0b4738      /dev/sda1       attached        2013-01-18T11:36:03+0000        true
EBS側から見ても、どのインスタンスにマウントされているのか…というのは分かるんですね。



・EBSのスナップショットを取得する
EBSのバックアップ作成用コマンドは ec2-create-snapshot  というものらしいです。
先に入手した volume-id をパラメータとして与えて、EBS Snapshot を作成します。
⇒ 作成されたバックアップは「EBS Snapshot」と呼ばれるみたい…。単なる Snapshot でも通じるみたいだけど、自信が無いので EBS Snapshot と呼んでおきます(^^;
⇒ ここでは使っていませんが ec2-create-snapshot に --description オプションを与えることで、Snapshot にコメントを付与できるようです。
$ ec2-create-snapshot vol-765ff554
SNAPSHOT        snap-a63b3886   vol-765ff554    pending 2013-01-28T11:26:21+0000                354893364746    8
コマンドを発行した直後は「バックアップ開始依頼した」というだけであって、完了までに時間がかかります。ec2-describe-snapshots コマントを利用して、状態を確認してみます。
$ ec2-describe-snapshots snap-a63b3886
SNAPSHOT        snap-a63b3886   vol-765ff554    completed       2013-01-28T11:26:21+0000        100%    354893364746        8
意外なほど早く処理が完了してしまいますね…。時間帯によっては違うのかもしれませんが…。



・AMIの登録
作成した EBS Snapshot を、EC2インスタンスの起動イメージとして使用できるよう、AMI(Amazon Machine Image)に登録してみます。
$ ec2-register \
     --snapshot snap-a63b3886 \
     --kernel-id aki-42992843 \
     --name master_amazonlinux \
     --description 'Master AmazonLinux'
IMAGE   ami-5120a550
--kernel-id の指定を忘れると、起動できない AMI が作成されることがあるので要注意。さらに --name と --description を付与して、AMIの用途などを追記しておきます。
登録されたAMIを確認してみます。
$ ec2-describe-images ami-5120a550
IMAGE   ami-5120a550    354893364746/master_amazonlinux 354893364746    available       private         i386    machine aki-42992843     ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-a63b3886   8       true    standard
基となった EBS Snapshot の IDも記録されていますね…。



・EBSからコマンド一発でAMI作成
ec2-create-snapshot と ec2-register を一回で同時に実行できるコマンドも存在するようです。ec2-create-image というものらしいので……さっそく実行してみましょう。
先ほど作成したものと区別するため、ここでは master2 という名前を付けておきます。
$ ec2-create-image i-3b0b4738 --name 'master2' --description 'test for ec2-create-image'
IMAGE   ami-5b20a55a
$
Broadcast message from root@ip-~
        (unknown) at 12:00 ...

The system is going down for reboot NOW!
Control-Alt-Delete pressed
Connection to ~.compute.amazonaws.com closed by remote host.
Connection to ~.compute.amazonaws.com closed.

あらら……
突然、ssh コマンドが切断されてしまいました。
というか、EC2インスタンス(AmazonLinux)自体が再起動されてしまったようです…。

どうやら、ec2-create-image コマンドを使用すると、EC2インスタンスが一時停止してしまうみたいですね…。
⇒ ということは、ec2-create-snapshot  の時も EC2インスタンスは一時停止しておいた方が良いのかなぁ…ディスクの中身の整合性なんかを考慮するなら、EC2インスタンスを停止しておいた方が良いんでしょうねぇ…。


気を取り直して、勝手に再起動した AmazonLinux に ssh で再接続し、EBS Snapshot と AMI が作成されているかどうか確認してみます。
$ ec2-describe-snapshots
SNAPSHOT        snap-a63b3886   vol-765ff554    completed       2013-01-28T11:26:21+0000        100%    354893364746        8
SNAPSHOT        snap-e3cccfc3   vol-765ff554    completed       2013-01-28T12:00:18+0000        100%    354893364746        8       Created by CreateImage(i-3b0b4738) for ami-5b20a55a from vol-765ff554

$ ec2-describe-images ami-5b20a55a
IMAGE   ami-5b20a55a    354893364746/master2    354893364746    available       private         i386    machine aki-42992843                        ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-e3cccfc3   8       true    standard
EBS Snapshot も AMI も、(コマンド発行元のサーバが再起動されたにも関わらず)キチンと作成されているようです。AWSコマンドは、実際には http リクエストで実現されているらしいですから、これはまぁ、期待通りの動作かも。
また、kernel-id を指定しませんでしたが、自動的に反映されています。これは楽で良いですね☆



・AMIの削除
後始末として、先ほど登録した 2つの AMI を消去します。精確には「登録の解除(deregister , unregister)」という作業ですが…。

まず、AMIのIDを調べます。
$ ec2-describe-images
IMAGE   ami-5b20a55a    354893364746/master2    354893364746    available       private         i386    machine aki-42992843                        ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-e3cccfc3   8       true    standard
IMAGE   ami-5120a550    354893364746/master_amazonlinux 354893364746    available       private         i386    machine aki-42992843                        ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-a63b3886   8       true    standard
次に、AMIのIDを指定して消去します。
$ ec2-deregister ami-5b20a55a
IMAGE   ami-5b20a55a
$ ec2-deregister ami-5120a550
IMAGE   ami-5120a550
最後に、AMIがホントに消えたどうかの確認。
$ ec2-describe-images
レスポンス表示が何もないので、消えてますね。



・EBS Snapshot を消す
次に、やはり後始末として 作成済みの EBS Snapshot を消去します。

まず、EBS Snapshot の ID を取得します。
$ ec2-describe-snapshots
SNAPSHOT        snap-a63b3886   vol-765ff554    completed       2013-01-28T11:26:21+0000        100%    354893364746        8
SNAPSHOT        snap-e3cccfc3   vol-765ff554    completed       2013-01-28T12:00:18+0000        100%    354893364746        8       Created by CreateImage(i-3b0b4738) for ami-5b20a55a from vol-765ff554
入手した EBS Snapshot のIDを指定して、ec2-delete-snapshot コマンドを実行します。消すのは一瞬かと思いきや、以外と時間がかかります(数秒程度?)。
$ ec2-delete-snapshot snap-a63b3886
SNAPSHOT        snap-a63b3886
$ ec2-delete-snapshot snap-e3cccfc3
SNAPSHOT        snap-e3cccfc3
最後に、ホントに消えたかどうかの確認。
$ ec2-describe-snapshots

ちなみに、EBS Snapshot を AMI として使用している場合、先にAMIを消さないと EBS Snapshot は消去できません。依存関係が存在するせいでしょう



これで、EC2インスタンスに使用された EBS(仮想HDD)を コマンドラインからバックアップ、再利用する方法を手に入れたことになります。



ところで、EBS Snapshot を EBS に書き戻すにはどうすれば良いんでしょうね???[謎]

コマンドライン ec2-delete-tags で消したハズの DESCRIPTION  というタグが、AWS Management Console 上ではいつまでも表示されている。中身は empty として表示されているので間違ってはいないのだが…何か気分が悪い。

ec2-describe-tags コマンドには --show-empty-fields というオプションがあるらしいので試してみたが、やはり DESCRIPTION のタグは表示されない。
$ ec2-describe-tags
TAG     instance        i-3b0b4738      Name    Master AmazonLinux

$ ec2-describe-tags --show-empty-fields
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
AWS Management Console 側の問題なのかなぁ…。



EC2 Instances を表示している状態で 歯車アイコン をクリックすれば、表示する tag を選択できるけれど…(ソレは期待する回答ではない)。



.
.
.


あ!

ブラウザの cookie と インターネット一時ファイル(キャッシュ)を消去したら、AWS Management Console から DESCRIPTION の tag が消えた…。
わざわざキャッシュで覚えちゃうんですね...。このへんはコマンドラインの挙動/結果とは違違うので注意が必要です。

前回やったコマンドラインによるEC2インスタンス作成では、tagが付きませんでした。

今回は、コマンドライン(CUI)を使用して、EC2インスタンスにtagを付けてみます。



・tagを付けるためのコマンドを探す
AmazonLinux では、AWSコマンドは /opt/aws/bin/ の配備されています。ここから tag というファイル名を持つファイルを探します。
$ ls -1 /opt/aws/bin/*tag*
/opt/aws/bin/as-create-or-update-tags
/opt/aws/bin/as-delete-tags
/opt/aws/bin/as-describe-tags
/opt/aws/bin/ec2addtag
/opt/aws/bin/ec2-create-tags
/opt/aws/bin/ec2-delete-tags
/opt/aws/bin/ec2-describe-tags
/opt/aws/bin/ec2dtag
/opt/aws/bin/ec2tag
/opt/aws/bin/rds-add-tag-to-resource
/opt/aws/bin/rds-list-tags-for-resource
/opt/aws/bin/rds-remove-tags-from-resource
ザっと眺める限りでは、ec2-describe-tags、ec2-create-tags、ec2-delete-tags が関連するコマンドのようですね。
⇒ AWS操作コマンドのマニュアルがどこにあるのか知らないので、いつもこんな感じで探してます……。



・tagの追加
現在起動しているECインスタンスのタグ一覧を取得してみます。
$ ec2-describe-tags
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
コマンドライン操作に使用している AmazonLinux サーバのみなので、上記のような結果になっていますね。これに新しいtagを追加してみます。
$ ec2-create-tags \
     i-3b0b4738 \
     --tag DESCRIPTION='Command line server'
TAG     instance        i-3b0b4738      DESCRIPTION     Command line server

$ ec2-describe-tags
TAG     instance        i-3b0b4738      DESCRIPTION     Command line server
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
バッチリ追加されたようです。



・特定のタグだけ探す
ec2-describe-tags には、--filtyer オプションを使用して特定のタグを持つものだけを検索する機能もあるようです。
$ ec2-describe-tags  i-3b0b4738 --filter key=name

$ ec2-describe-tags  i-3b0b4738 --filter key=Name
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
$ ec2-describe-tags  i-3b0b4738 --filter value=master*

$ ec2-describe-tags  i-3b0b4738 --filter value=Master*
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
挙動を見る限り、--filter オプションで検索する場合には、キー、バリュー両方とも 大文字小文字が区別されている(= Case Sensitive)様子…。


実際には、EC2インスタンスに与えたtagでサーバの挙動を変えることは無いのかもしれないけれど…。AWS  Management Console でインスタンスを区別するには便利なので、結構使うと思います。



・tagの削除
tagを削除するには ec2-delete-tags を使うのですが…
$ ec2-delete-tags i-3b0b4738 -tag DESCRIPTION
TAG     instance        i-3b0b4738      DESCRIPTION     Command line server

$ ec2-describe-tags
TAG     instance        i-3b0b4738      DESCRIPTION     Command line server
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
なぜか tag を消せません。

EC2インスタンスは自分自身のタグを消去できないのかと思って、他のインスタンスから実行してみましたが やはり 消せませんでした。CUI プログラムのバージョンが古いのかと思って yum update をしてみましたが、やはり効果なし…

ん...

tag の value を空文字にして、それから消去したら良いのでは……と想像したので実行してみます。
$ ec2-create-tags  i-3b0b4738  --tag DESCRIPTION=
TAG     instance        i-3b0b4738      DESCRIPTION

$ ec2-describe-tags
TAG     instance        i-3b0b4738      DESCRIPTION
TAG     instance        i-3b0b4738      Name    Master AmazonLinux

$ ec2-delete-tags i-3b0b4738  --tag DESCRIPTION=
TAG     instance        i-3b0b4738      DESCRIPTION

$ ec2-describe-tags
TAG     instance        i-3b0b4738      Name    Master AmazonLinux

消えた!!!

ちなみに「ec2-delete-tags i-3b0b4738  --tag DESCRIPTION=」じゃなく「ec2-delete-tags i-3b0b4738  --tag DESCRIPTION」でも消せました。
つまり、「tagを消去する前にはいったん空文字列を設定し、それからtag自身を消去する」という手順ならOKらしい。バグっぽいな…まぁ、消せるから良いけど…。


これで EC2インスタンスに tag を自由に追加/削除できるようになりました。



今回はここまで。

今回は、コマンドライン(CUI)から EC2インスタンを 作成、削除する操作を行います。


・前準備

以前の手順に従って、AmazonLinux を OS とする EC2インスタンスを起動します。起動した AmazonLinux に ssh 接続し、アクセスキー設定もしておいてください。
AWS上に用意した AmazonLinux環境経由でなく、ローカルPCに Amazonが提供するコマンドライン用のツールをインストールしておいても構いません(ソチラの方が普通かも???)。



・リージョンを固定するための設定
まず、AWS側に登録済みの keypais (ssh鍵)の確認してみます。
$ ec2-describe-keypairs
あれ? 何も表示されませんけど...。ここでは、default という keypair が存在するはずなのですが…。 ec2-describe-keypairs --help として、ヘルプを見てみましょう。
-U, --url URL
    Specify URL as the web service URL to use. Defaults to the value of
    'https://ec2.amazonaws.com' (us-east-1) or to that of the
    EC2_URL environment variable (if set). Overrides the default.

--region REGION
    Specify REGION as the web service region to use.
    This option will override the URL specified by the "-U URL" option
    and EC2_URL environment variable.
    This option defaults to the region specified by the EC2_URL environment variable
    or us-east-1 if this environment variable is not set.
ヘルプを見てみると上記のように記載されています。つまり、環境変数 EC2_URL あるいは --url / --region オプションで指定しない限り、us-east-1 がデフォルトのリージョンとして使用されてしまうようです。
毎回手動で設定するのもメンドクサイので、環境変数設定用のバッチに追記しておくことにします。
cat ~/bin/initaws.sh
#!/bin/sh
export AWS_ACCESS_KEY='アクセスキー文字列'
export AWS_SECRET_KEY='シークレットアクセスキー文字列'
export EC2_URL='ec2.ap-northeast-1.amazonaws.com'
これで、特に指定しなければ tokyo リージョンが指定されることになります。用意したバッチを使って、環境変数 EC2_URL を設定しておいてください。
source ~/bin/initaws.sh
環境変数を設定してから、ec2-describe-keypairs もう一度実行してみると……
$ ec2-describe-keypairs
KEYPAIR default **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**
バッチリ。ちゃんと tokyo リージョンに登録されているはずの default という名前の鍵が表示されています。



・新しい鍵ペアの登録
keypair を追加するには ec2-add-keypair (ec2addkey や ec2-create-keypair でも同じらしい)というコマンドを使用するみたい。ここでは sample というキーペアを作成してみます。
$ ec2-add-keypair sample
KEYPAIR sample  63:*5:*0:*d:*6:*8:*0:*9:*5:*3:*3:*f:*a:*f:*e:*2:*3:*e:*4:22
-----BEGIN RSA PRIVATE KEY-----
*II*pA*BA*KC*QE*kW*Yx*MH*W9*+F*r6*28*+U*6i*Wf*cU*Jc*3M*54*qy*lp*af*FO*Ed*NG*



*2q*/S*GS*Ns*4k*cz*4t*B1*au*yG*qc*HB*6B*xf*RK*tv*dR*uE*Gp*ss*bw*4T*q/*==
-----END RSA PRIVATE KEY-----
出力結果の一行目はフィンガープリントで、二行目以下が秘密鍵ファイルですね…。二行目以降の部分(-----BEGIN RSA PRIVATE KEY----- 以降の部分)を sample.pem として保存しておいてください。ここでは ~/.ssh/sample.pem として保存しておきます。
⇒ 保存した pem ファイルのpermissionを設定、他人から読み取られないようにしておいてください。
    chmod og= ~/.ssh/sample.pem とします。
   この操作をしていないと、後で、ssh コマンドを使用する際にエラーになってしまいます。


・セキュリティグループの作成
ファイアーウォールというか iptables というか、それらに相当するのがAWSのセキュリティグループらしいです。何も設定していないと、デフォルトですべての通信を遮断するらしいので、ここでは 22番(ssh)ポートを解放する sample という名前のグループを設定します。

セキュリティグループを作成するコマンドは ec2-add-group (ec2-create-group、ec2addgrp でも同義らしい)です。ここでは sample という名前の新規グループを作成します。
$ ec2-add-group sample --description 'sample security group'
GROUP   sg-692e5b68     sample  sample security group
出来たばかりセキュリティグループには、何も設定(フィルタ)が無いので、 22~25番ポート(ssh)を通過させる設定を追加します(23,24,25 ポートは不要ですが、範囲指定のサンプルとして開放しています)
セキュリティグループにフィルタ設定を追加するのは ec2-authorize (ec2auth でも同じ)コマンドで、以下のように設定します。
$ ec2-authorize \
     sample \
     --protocol tcp \
     --port-range 22-25 \
     --cidr '0.0.0.0/0'
GROUP                   sample
PERMISSION              sample  ALLOWS  tcp     22      25      FROM    CIDR    0.0.0.0/0       ingress
ingress は「外から中に向かってパケットが通過する場合の設定」ということらしいです。
反対は egress。

とりあえず、これでセキュリティグループは出来たつもり。



・EC2インスタンスの作成
EC2インスタンスを起動するためのコマンドは ec2-run-instances (ec2run でもOK) です。ヘルプをザッと眺める限り、ここで指定しておいた方が良さそうなパラメータは以下の通り。
AMI識別子(ブートイメージ)
--group セキュリティグループ(複数指定可能)
--key 使用するkeypair
--instance-count 起動するインスタンスの数
--instance-type インスタンスタイプ(マイクロとかラージとか)
--availability-zone AZ。指定しなければ適当な場所が選択されるらしい…
--disable-api-termination TerminationProtectionの設定
--instance-initiated-shutdown-behavior シャットダウン時の挙動(stop/terminate)
AMI識別子は…ec2-describe-images で探せるらしいのですが、--filter オプションを使ってもウマク探せませんでした。AWS Management Console (のEC2起動用 ClassicWizard)から探すか、あるいは ec2-describe-images --all として出力されたものの中から探すか…になると思います。AM識別子が分かっているなら、ソレを使うと良いでしょう。
ここでは、Ubuntu Server 12.04.1 LTS である ami-20ad1221 を使用することにします。

セキュリティグループは今回は1つしか使用しません。複数設定する場合は --group A --group B --group C ...というように、オプションを複数回使用するようです(※未調査)。

インスタンスタイプは…コマンドラインから直接識別子を得る方法が分かりませんでした。Amazon のサイトにインスタンスタイプ一覧があったので、そこから識別子を抽出して利用します。マイクロは「t1.micro」となるようです。
⇒ http://aws.amazon.com/jp/ec2/instance-types/

AvailabilityZones は ec2-describe-availability-zones コマンドで一覧が入手できます。全リージョンのものを一度に入手することはできないようなので、希望するリージョンを指定する必要があります。
$ ec2-describe-availability-zones
AVAILABILITYZONE        ap-northeast-1a available       ap-northeast-1
AVAILABILITYZONE        ap-northeast-1b available       ap-northeast-1
AVAILABILITYZONE        ap-northeast-1c available       ap-northeast-1

$ ec2-describe-regions
REGION  eu-west-1       ec2.eu-west-1.amazonaws.com
REGION  sa-east-1       ec2.sa-east-1.amazonaws.com
REGION  us-east-1       ec2.us-east-1.amazonaws.com
REGION  ap-northeast-1  ec2.ap-northeast-1.amazonaws.com
REGION  us-west-2       ec2.us-west-2.amazonaws.com
REGION  us-west-1       ec2.us-west-1.amazonaws.com
REGION  ap-southeast-1  ec2.ap-southeast-1.amazonaws.com
REGION  ap-southeast-2  ec2.ap-southeast-2.amazonaws.com

$ ec2-describe-availability-zones --region eu-west-1
AVAILABILITYZONE        eu-west-1a      available       eu-west-1
AVAILABILITYZONE        eu-west-1b      available       eu-west-1
AVAILABILITYZONE        eu-west-1c      available       eu-west-1
最終的に、EC2インスタンスを作成するためのコマンドは以下のような感じ。
$ ec2-run-instances  ami-20ad1221 \
     --group sample  \
     --key sample  \
     --instance-count 1  \
     --instance-type t1.micro  \
     --availability-zone ap-northeast-1a  \
     --disable-api-termination  \
     --instance-initiated-shutdown-behavior stop

RESERVATION     r-3763df34      354893364746    sample
INSTANCE        i-15490116      ami-20ad1221                    pending sample  0               t1.micro        2013-01-21T13:39:27+0000       ap-northeast-1a aki-ec5df7ed                    monitoring-disabled                                     ebs                                    paravirtual     xen             sg-692e5b68     default false

実行してしばらく待てば EC2インスタンスの起動が完了します。ec2-describe-instance コマンドで確認すれば、起動が完了したかどうか分かります。インスタンスID(i-で始まる識別子)を指定すれば、そのインスタンスだけ調べられます。

起動が完了すれば、ssh でログインできます。
ssh -i ~/.ssh/sample.pem -l ubuntu YOUHOSTNAME.compute.amazonaws.com


・EC2インスタンスの削除
作成したEC2インスタンスは不要になったら削除します。まずは、インスタンスを STOP させます。

$ ec2-stop-instances i-15490116
INSTANCE        i-15490116      running stopping

$ ec2-describe-instances i-15490116
RESERVATION     r-3763df34      354893364746    sample
INSTANCE        i-15490116      ami-20ad1221    ec2-54-248-202-225.ap-northeast-1.compute.amazonaws.com ip-10-132-98-57.ap-northeast-1.compute.internal        stopping        sample  0               t1.micro        2013-01-21T13:39:27+0000        ap-northeast-1a        aki-ec5df7ed                    monitoring-disabled     54.248.202.225  10.132.98.57                    ebs                                    paravirtual     xen             sg-692e5b68     default false
BLOCKDEVICE     /dev/sda1       vol-8f02b5ad    2013-01-21T13:39:31.000Z        true

$ ec2-describe-instances i-15490116
RESERVATION     r-3763df34      354893364746    sample
INSTANCE        i-15490116      ami-20ad1221                    stopped sample  0               t1.micro        2013-01-21T13:39:27+0000       ap-northeast-1a aki-ec5df7ed                    monitoring-disabled                                     ebs                                    paravirtual     xen             sg-692e5b68     default false
BLOCKDEVICE     /dev/sda1       vol-8f02b5ad    2013-01-21T13:39:31.000Z        true
インスタンスのSTOP状態が確認できたら、次は TerminationProtectionを解除します。

AWSのマニュアルによるとTerminationProtectionを disable にするための専用コマンドは無いみたいなので、汎用のコマンドで設定解除します。
⇒ http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Using_ChangingDisableAPITermination.html
$ ec2-modify-instance-attribute i-15490116 --disable-api-termination false
disableApiTermination   i-15490116      false
ec2-modify-instance-attribute という長~いコマンド名に、EC2インスタンスID と合わせて解除指定を行えばOK。インスタンス作成時と違って、すぐに応答があります。


最後に、EC2インスタンスを terminate します。ec2-terminate-instances (ec2kill というのも同義らしい)コマンドを使います。
$ ec2-terminate-instances i-15490116
INSTANCE        i-15490116      stopped terminated
Terminate 処理が完了しているかどうか、ec2-describe-instances で確認しておきましょう。
$ ec2-describe-instances i-15490116
RESERVATION     r-3763df34      354893364746    sample
INSTANCE        i-15490116      ami-20ad1221                    terminated      sample  0               t1.micro        2013-01-21T13:39:27+0000       ap-northeast-1a aki-ec5df7ed                    monitoring-disabled                                    ebs                                     paravirtual     xen             sg-692e5b68     default false
ちゃんと、teminated となっていますね。



・セキリティグループの削除
今回作った sample というセキュリティグループを削除します。
ec2-delete-group コマンド(ec2delgrpでも同じ)を使います。
$ ec2-delete-group sample
RETURN  true
キチンと消えたかどうか、ec2-describe-group を使って確認しておいてください。



・keypair の削除
ここでは、sample という名のkeypair を作りましたが、もう使わないので削除しておきます。間違った鍵を消さないように注意してください(^^;
$ ec2-delete-keypair sample
KEYPAIR sample
こちらも、キチンと消えたかどうか ec2-describe-keypairs コマンドで確認しておいてください。




これで、EC2インスタンスの起動と終了を コマンドラインから操作できるようになりました!
















このページのトップヘ