今回は、EBS (仮想化HDD)のバックアップを作成し、そこからAMI(ブートイメージ)を作成してみます。もちろん、コマンドライン(CUI)で……。
・最初のEC2インスタンス
AmazonLinux を OS として、EC2インスタンス(Micro 32bit, EBS)を起動し、その上で作業します。つまり、今回の作業は自分自身をバックアップする…ということになります。
後から必要になるので「起動したEC2インスタンス上で、自分自身の instance-idを取得」しておきます。
また、同じようにしてEC2 インスタンスが使用している kernel-id も取得しておきます。
・EBSのID (volume-id)を調べる
まずは、起動している AmazonLinux にマウントされている EBS の ID を調べます。
先に調べておいた EC2の instance-id をパラメータとして ec2-describe-instances コマンドを使用します。
では、次に、EBS の状態を見てみましょう。
・EBSのスナップショットを取得する
EBSのバックアップ作成用コマンドは ec2-create-snapshot というものらしいです。
先に入手した volume-id をパラメータとして与えて、EBS Snapshot を作成します。
⇒ 作成されたバックアップは「EBS Snapshot」と呼ばれるみたい…。単なる Snapshot でも通じるみたいだけど、自信が無いので EBS Snapshot と呼んでおきます(^^;
⇒ ここでは使っていませんが ec2-create-snapshot に --description オプションを与えることで、Snapshot にコメントを付与できるようです。
・AMIの登録
作成した EBS Snapshot を、EC2インスタンスの起動イメージとして使用できるよう、AMI(Amazon Machine Image)に登録してみます。
登録されたAMIを確認してみます。
・EBSからコマンド一発でAMI作成
ec2-create-snapshot と ec2-register を一回で同時に実行できるコマンドも存在するようです。ec2-create-image というものらしいので……さっそく実行してみましょう。
先ほど作成したものと区別するため、ここでは master2 という名前を付けておきます。
突然、ssh コマンドが切断されてしまいました。
というか、EC2インスタンス(AmazonLinux)自体が再起動されてしまったようです…。
どうやら、ec2-create-image コマンドを使用すると、EC2インスタンスが一時停止してしまうみたいですね…。
⇒ ということは、ec2-create-snapshot の時も EC2インスタンスは一時停止しておいた方が良いのかなぁ…ディスクの中身の整合性なんかを考慮するなら、EC2インスタンスを停止しておいた方が良いんでしょうねぇ…。
気を取り直して、勝手に再起動した AmazonLinux に ssh で再接続し、EBS Snapshot と AMI が作成されているかどうか確認してみます。
また、kernel-id を指定しませんでしたが、自動的に反映されています。これは楽で良いですね☆
・AMIの削除
後始末として、先ほど登録した 2つの AMI を消去します。精確には「登録の解除(deregister , unregister)」という作業ですが…。
まず、AMIのIDを調べます。
・EBS Snapshot を消す
次に、やはり後始末として 作成済みの EBS Snapshot を消去します。
まず、EBS Snapshot の ID を取得します。
ちなみに、EBS Snapshot を AMI として使用している場合、先にAMIを消さないと EBS Snapshot は消去できません。依存関係が存在するせいでしょう。
これで、EC2インスタンスに使用された EBS(仮想HDD)を コマンドラインからバックアップ、再利用する方法を手に入れたことになります。
ところで、EBS Snapshot を EBS に書き戻すにはどうすれば良いんでしょうね???[謎]
・最初のEC2インスタンス
AmazonLinux を OS として、EC2インスタンス(Micro 32bit, EBS)を起動し、その上で作業します。つまり、今回の作業は自分自身をバックアップする…ということになります。
後から必要になるので「起動したEC2インスタンス上で、自分自身の instance-idを取得」しておきます。
$ curl 'http://169.254.169.254/latest/meta-data/instance-id'; echo -en '\n'http://169.254.169.254/ にhttpアクセスすれば、アクセス元のEC2インスタンス情報をレスポンスとして得られます。その中に instance-id が存在するので、ソレを使うことにします。
i-3b0b4738
また、同じようにしてEC2 インスタンスが使用している kernel-id も取得しておきます。
$ curl 'http://169.254.169.254/latest/meta-data/kernel-id'; echo -en '\n'kernel-id が無いと、この後 作成する AMI (AmazonMachineImage)が「正しく起動しない」ものになってしまうので…。使用しているOSやインスタンスタイプによっては、指定しなくても動作するかもしれませんが…。
aki-42992843
・EBSのID (volume-id)を調べる
まずは、起動している AmazonLinux にマウントされている EBS の ID を調べます。
先に調べておいた EC2の instance-id をパラメータとして ec2-describe-instances コマンドを使用します。
$ ec2-describe-instances i-3b0b4738/dev/sda1 にマウントされているのは vol-765ff554 という EBS になっているようです。
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
では、次に、EBS の状態を見てみましょう。
$ ec2-describe-volumes vol-765ff554EBS側から見ても、どのインスタンスにマウントされているのか…というのは分かるんですね。
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のバックアップ作成用コマンドは ec2-create-snapshot というものらしいです。
先に入手した volume-id をパラメータとして与えて、EBS Snapshot を作成します。
⇒ 作成されたバックアップは「EBS Snapshot」と呼ばれるみたい…。単なる Snapshot でも通じるみたいだけど、自信が無いので EBS Snapshot と呼んでおきます(^^;
⇒ ここでは使っていませんが ec2-create-snapshot に --description オプションを与えることで、Snapshot にコメントを付与できるようです。
$ ec2-create-snapshot vol-765ff554コマンドを発行した直後は「バックアップ開始依頼した」というだけであって、完了までに時間がかかります。ec2-describe-snapshots コマントを利用して、状態を確認してみます。
SNAPSHOT snap-a63b3886 vol-765ff554 pending 2013-01-28T11:26:21+0000 354893364746 8
$ 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 \--kernel-id の指定を忘れると、起動できない AMI が作成されることがあるので要注意。さらに --name と --description を付与して、AMIの用途などを追記しておきます。
--snapshot snap-a63b3886 \
--kernel-id aki-42992843 \
--name master_amazonlinux \
--description 'Master AmazonLinux'
IMAGE ami-5120a550
登録されたAMIを確認してみます。
$ ec2-describe-images ami-5120a550基となった EBS Snapshot の IDも記録されていますね…。
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からコマンド一発で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-snapshotsEBS Snapshot も AMI も、(コマンド発行元のサーバが再起動されたにも関わらず)キチンと作成されているようです。AWSコマンドは、実際には http リクエストで実現されているらしいですから、これはまぁ、期待通りの動作かも。
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
また、kernel-id を指定しませんでしたが、自動的に反映されています。これは楽で良いですね☆
・AMIの削除
後始末として、先ほど登録した 2つの AMI を消去します。精確には「登録の解除(deregister , unregister)」という作業ですが…。
まず、AMIのIDを調べます。
$ ec2-describe-images次に、AMIのIDを指定して消去します。
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
$ ec2-deregister ami-5b20a55a最後に、AMIがホントに消えたどうかの確認。
IMAGE ami-5b20a55a
$ ec2-deregister ami-5120a550
IMAGE ami-5120a550
$ ec2-describe-imagesレスポンス表示が何もないので、消えてますね。
・EBS Snapshot を消す
次に、やはり後始末として 作成済みの EBS Snapshot を消去します。
まず、EBS Snapshot の ID を取得します。
$ ec2-describe-snapshots入手した EBS Snapshot のIDを指定して、ec2-delete-snapshot コマンドを実行します。消すのは一瞬かと思いきや、以外と時間がかかります(数秒程度?)。
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-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 に書き戻すにはどうすれば良いんでしょうね???[謎]
コメント
コメント一覧 (5)
Cheap Jerseys wholesale http://www.slp.cc/asles.cfm