株式会社ライブキャストロゴ 株式会社ライブキャスト

当サイトをAmazon EC2 Micro Instancesで運用開始してから、4ヶ月がたちました。
Instanceは「Root Device Type」が「ebs」のAmazon Machine Image(AMI)をlaunchしています。
Amazon EC2 Micro Instancesでの運用を開始しました

4ヶ月もたつとWordPressがバージョンアップしたり、導入中プラグインがバージョンアップしたりで更新が必要なものがいくつか出てきます。特に、脆弱性の対応がされたものなどはいち早く導入したいものです。

ですが、使用中のテーマなどが対応していなかったりすると、不用意なバージョンアップでデザインが崩れたり、最悪は画面が表示されなかったりするかもしれません。

これは、極力避けたいです。

そんな時、以前参加したAmazon EC2のセミナーのことを思い出しました。

AWS Management Console上に表示されている、インスタンス一覧のコンテキストメニューから、「Create Image(EBS AMI)」を選択することで、インスタンスのバックアップができるようです。

Amazon EC2のセミナーに参加しました!より引用。

ただ、

但し、再起動するのでしばらく使用不能になる、とのこと。

と聞いていたので、どうするか悩んでいたのですが、

AWS Management ConsoleとAmazon EC2 API Toolsを併用することで、使用不能になることは回避できるらしいです。

再起動させないやり方もあるようなので、実際に試してみました。

ということで、運用中のInstanceを停止せずにCreate Image(EBS AMI)する方法をご紹介したいと思います。

全体の流れ

全体の流れをまとめます。

  1. 運用中インスタンスのイメージファイルを作成する。
  2. 作成したイメージファイルを1つにする。
  3. AWS Management ConsoleでEBS Volumeを作成する。
  4. 作成したVolumeをAWS Management ConsoleでInstanceにattachする。
  5. attachしたVolumeをマウントする。
  6. イメージをマウントしたVolumeにコピーする。
  7. VolumeからSnapshotを作成する。
  8. 作成したSnapshotからAMIを作成する。
  9. マウントを解除する。

この手順に沿って進めていきます。
すべてサーバ上のコマンド実行で進めることもできるのですが、今回は3、4をAWS Management Consoleで実施しました。

※ こちらのサイトを参考にさせていただきました。
EBSタイプのAMI作成
EBSタイプのインスタンスを他リージョンへ移行する手順 « サーバーワークス技術ブログ

AMIを作成する

まず、sshでサーバにログインしたら、/etc/fstabをviで開いて、状態を確認します。

[ec2-user@ip-10-112-99-245 ~]$ vi /etc/fstab
#
LABEL=/ / ext3 defaults,noatime 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
ephemeral0 None auto defaults,comment=cloudconfig 0 2
swap None swap sw,comment=cloudconfig 0 0

※ 後述で、コピー後のfstabとの比較に使います。

1.運用中インスタンスのイメージファイルを作成する。

[root@ip-10-112-99-245 ec2-user]# ec2-bundle-vol -d /mnt/ -k pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem -c cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem -u 64XXXXXXXXXX
Please specify a value for arch [i386]: i386
Copying / into the image file /mnt/image…
Excluding:
/sys
/proc
/dev/pts
/proc/sys/fs/binfmt_misc
/dev
/media
/mnt
/proc
/sys
/mnt/image
/mnt/img-mnt
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00338697 seconds, 310 MB/s
mke2fs 1.41.12 (17-May-2010)
warning: Unable to get device geometry for /mnt/image
Bundling image file…
Splitting /mnt/image.tar.gz.enc…
Created image.part.00
Created image.part.01
Created image.part.02
Created image.part.03
Created image.part.04
Created image.part.05
Created image.part.06
Created image.part.07
Created image.part.08
Created image.part.09
Created image.part.10
Created image.part.11
Created image.part.12
Created image.part.13
Created image.part.14
Created image.part.15
Created image.part.16
Created image.part.17
Created image.part.18
Created image.part.19
Created image.part.20
Created image.part.21
Created image.part.22
Created image.part.23
Created image.part.24
Created image.part.25
Created image.part.26
Created image.part.27
Created image.part.28
Created image.part.29
Created image.part.30
Created image.part.31
Created image.part.32
Created image.part.33
Created image.part.34
Created image.part.35
Created image.part.36
Created image.part.37
Generating digests for each part…
Digests generated.
Unable to read instance meta-data for ancestor-ami-ids
Unable to read instance meta-data for ramdisk-id
Unable to read instance meta-data for product-codes
Creating bundle manifest…
ec2-bundle-vol complete.

※ pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem(X.509証明書)とcert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem(X.509秘密鍵)、64XXXXXXXXXX(Account Number)は適宜、読み替えていただけるようお願いします。以降、同様となります。

2.作成したイメージファイルを1つにする。

[root@ip-10-112-99-245 ec2-user]# ec2-unbundle -k pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem -m /mnt/image.manifest.xml -s /mnt/ -d /mnt/
Unbundle complete.

3.AWS Management ConsoleでEBS Volumeを作成する。

AWS Management Consoleの左ペインより「Volumes」を選択します。「Create volume」を押すと、作成するVolumeの情報を入力する画面が表示されます。

Sizeは10GiBを指定しました。Availability Zoneは、Instanceが稼動しているZoneと同じ場所を指定します。「Create」ボタンをクリックしてしばらくすると、Volumeが作成されます。

「Status」が青く「available」となったら、使用可能です。

4.作成したVolumeをAWS Management ConsoleでInstanceにattachする。

続いて、作成したVolumeをInstanceにattachします。Volumeを選択して右クリックすると、コンテキストメニューが表示されます。

メニューより、「Attach Volume」を選択すると、attachするVolumeとInstanceの情報を入力する画面が表示されます。

Instancesには、稼働中InstanceのリストからattachするInstanceを選択します。また、Deviceは、とりあえず「/dev/sdh」としました。「Attach」ボタンをクリックしてしばらくすると、VolumeがInstanceにattachされます。

attachされると、「Status」が緑色で「in-use」になります。

5.attachしたVolumeをマウントする。

続いて、attachしたVolumeをマウントします。

[ec2-user@ip-10-112-99-245 ~]$ sudo su
[root@ip-10-112-99-245 ec2-user]# mkdir /mnt/ebs
[root@ip-10-112-99-245 ec2-user]# mount /dev/sdh /mnt/ebs/
mount: you must specify the filesystem type

何故かエラーが出てマウントできません。マウントしようとしているデバイスがファイルシステムとして、認識されていないようです。

[root@ip-10-112-99-245 ec2-user]#ls -lv /dev

コマンドをたたいてみると、/dev/sdhが見つかりません。よく見ると、

brw-rw—- 1 root disk    202,   1 Mar  4 09:41 xvda1
brw-rw—- 1 root disk    202, 112 Mar  4 14:48 xvdh

という表示があることに気づきました。xvda1は、最初にEBSタイプのAMIからInstanceを起動したときに作成されたVolumeを示しているようです。AWS Management Consoleの表示では、/dev/sda1となっています。

ということは、/dev/sdhを示しているのはxvdhのほうなのではないかと思い、もう一度試してみました。

[root@ip-10-112-99-245 ec2-user]# mount /dev/xvdh /mnt/ebs/
mount: you must specify the filesystem type

が、まだだめです。今度は、Volumeにファイルシステムが作成されていないのでエラーになったようです。

最近発表されたストレージサービスAmazon EBS(Elastic Block Store)をEC2から利用する – RX-7乗りの適当な日々を参考に、以下のコマンドで、Volumeにファイルシステムを作成してみます。

[root@ip-10-112-99-245 ec2-user]# yes | mkfs -t ext3 /dev/xvdh
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
655360 inodes, 2621440 blocks
131072 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2684354560
80 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

今度はうまくいきそうな気がします。再度、マウントにチャレンジです。

[root@ip-10-112-99-245 ec2-user]# mount /dev/xvdh /mnt/ebs
[root@ip-10-112-99-245 ec2-user]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1            10321208   1410872   8805480  14% /
tmpfs                   308560         0    308560   0% /dev/shm
/dev/xvdh             10321208    154232   9642688   2% /mnt/ebs

ふー。やっとうまくいきました。

※ 後で調べたのですが、Xenの仮想化環境では、パーティションまたはデバイスがxvdの形式になるようです。
※ dfコマンドは、ディスクの使用状況を確認するコマンドのようです。
UNIXの部屋 コマンド検索:df (*BSD/Linux)

6.イメージをマウントしたVolumeにコピーする。

2.で1つに固めたイメージファイルをVolumeにコピーします。

[root@ip-10-112-99-245 ec2-user]# dd if=/mnt/image of=/dev/xvdh
20971520+0 records in
20971520+0 records out
10737418240 bytes (11 GB) copied, 1547.75 seconds, 6.9 MB/s

参考にさせていただいたサイトでは、この後、fstabの編集をしていたのですが、最初に確認したfstabと特に変化がなかったため、何もしませんでした。

[root@ip-10-112-99-245 ec2-user]# vi /mnt/ebs/etc/fstab
#
LABEL=/     /           ext3    defaults,noatime  1   1
tmpfs       /dev/shm    tmpfs   defaults        0   0
devpts      /dev/pts    devpts  gid=5,mode=620  0   0
sysfs       /sys        sysfs   defaults        0   0
proc        /proc       proc    defaults        0   0
ephemeral0      None    auto    defaults,comment=cloudconfig    0       2
swap    None    swap    sw,comment=cloudconfig  0       0

※ ddコマンドは、ファイルをデバイスにコピーする際などに使うコマンドのようです。
UNIXの部屋 コマンド検索:dd (*BSD/Linux)

7.VolumeからSnapshotを作成する。

[root@ip-10-112-99-245 ec2-user]# ec2-create-snapshot vol-feb5fa96 –description flashcast_20110305 -K pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem -C cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem
SNAPSHOT        snap-34dc5a58   vol-feb5fa96    pending 2011-03-04T16:04:53+0000                64XXXXXXXXXX    10flashcast_20110305

snapshotができました。

8.作成したSnapshotからAMIを作成する。

[root@ip-10-112-99-245 ec2-user]# ec2-register –snapshot snap-34dc5a58 –description=flashcast_20110305 –architecture i386 –root-device-name /dev/xvda1 -K pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem -C cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem –name flashcast_20110305
Client.InvalidBlockDeviceMapping: Invalid device name /dev/xvda1

なにかエラーが出ています。デバイス名のパラメータを/dev/xvda1で実行したのですが、デバイス名が正しくないようです。

[root@ip-10-112-99-245 ec2-user]# ec2-register –snapshot snap-34dc5a58 –description=flashcast_20110305 –architecture i386 –root-device-name /dev/sda1 -K pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem -C cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem –name flashcast_20110305
IMAGE   ami-3abd4f53

今度はちゃんとAMIができました。ここでは、/dev/xvda1ではなく/dev/sda1の方を指定しないといけないみたいです。

9.マウントを解除する。

最後に、マウントを解除します。

[root@ip-10-112-99-245 ec2-user]# umount /mnt/ebs/
[root@ip-10-112-99-245 ec2-user]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1            10321208   3117572   7098780  31% /
tmpfs                   308560         0    308560   0% /dev/shm

以上で、すべての手順が完了しました。運用中のInstanceを停止せずにCreate Image(EBS AMI)することができました!

作成したEBS AMIからInstanceをlaunchする

作成したEBS AMIが正常に機能するか、Instanceを起動して確認してみます。AWS Management Consoleの左ペインより「AMIs」を選択します。一覧から作成したAMIを選択して「Launch」ボタンをクリックすると、起動するInstanceの情報を入力する画面が表示されます。

Kernel IDは、コピー元である運用中のInstanceと同じものをリストから選択します。

コマンドからKernel IDを確認することもできます。

[root@ip-10-112-99-245 ec2-user]# ec2-metadata -k
kernel-id: aki-407d9529

他の項目はデフォルトのまま起動しました。「Continue」ボタンをクリックしてInstanceを起動します。以降は、通常のInstance起動時と同じです。しばらくするとInstanceが立ち上がりますので、ブラウザでサイトにアクセスしてみます。

運用中のInstanceとまったく同じ状態で、正常にサイトが表示されました!

途中、何度かはまりそうになりましたが、なんとかInstanceを再起動することなくCreate Image(EBS AMI)することができました。もっと簡単な手順もあるような気がしますが、非常に勉強になったので良しとします。

で、実際にサイトがダウンしていなかったかというと、1の「運用中インスタンスのイメージファイルを作成」している間に、アラートメールが3通ほど届いていました。その間に、ブラウザでサイトにアクセスした際には正常に応答が返っていたので、完全にダウンしたわけではありませんが、高負荷のためつながりにくい時間帯が若干発生したかもしれません。AWS Management Consoleから、Create Image(EBS AMI)した際の再起動から立ち上がるまでの時間は、そんなにかかるわけではありませんので、ここは割り切って、これだけの手間をかけるよりも、AWS Management ConsoleからCreate Image(EBS AMI)するという選択肢もありだと思います。

※ サーバ監視はNubium Sentinelを使ってみるの設定を参考にしていただければと思います。