株式会社ライブキャスト

当サイトを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で開いて、状態を確認します。

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

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

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

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

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をマウントします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

snapshotができました。

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

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

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

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

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

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

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

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

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

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

他の項目はデフォルトのまま起動しました。「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を使ってみるの設定を参考にしていただければと思います。