Amazon EC2を使ってWordPressとプラグインをスマートにアップデートする

2011年3月24日 Amazon Web Service, MySQL, WordPress

Follow @mojyamojya

Root Device TypeがEBSのInstanceを停止せずにCreate Image（EBS AMI）する方法で、運用中のInstanceからEBS AMIを作成しました。

このAMIを使ってInstanceを立ち上げれば、運用中のInstanceとまったく同じ環境のサーバを立ち上げることができます。そして、WordPressやそのプラグインのアップデートを、本番サーバに切り替える前に、事前に動作確認をすることができるので、

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

という懸念も無くなります。

実際に試してみたので、手順をまとめておきたいと思います。

EBS AMIからInstanceをlaunchする

まず、作成したEBS AMIから本番環境と同一のInstanceを1つ立ち上げます。

AWS Management Consoleの左ペインから「AMIs」を選択します。Root Device TypeがEBSのInstanceを停止せずにCreate Image（EBS AMI）する方法で作成したAMIを選択し、Instanceを起動します。しばらくするとInstanceが立ち上がります。この時、まったく同じ環境のInstanceが2つあることになります。1つは、以前から立ち上げっぱなしの本番環境でURLがhttp://flashcast.jp/blog/、もう1つが、EC2で自動的に割り振られたPublic DNSのサイトです。

ブラウザから、後者のサイトにアクセスします。

Public DNSがec2-184-73-63-24.compute-1.amazonaws.comだった場合、URLはhttp://ec2-184-73-63-24.compute-1.amazonaws.comになります。当ブログに当てはめるとhttp://ec2-184-73-63-24.compute-1.amazonaws.com/blog/となります。
※ 184-73-63-24の部分はパブリックIPです。
※ このPublic DNSはElastic IP割り当て前のものですので、現在は、このURLではアクセスできません。

http://ec2-184-73-63-24.compute-1.amazonaws.com/blog/にはアクセスできたのですが、WordPressの管理者サイトにアクセスすると、本番環境の管理者サイトにリダイレクトされていしまいました。

これは、以前、準備段階で発生した、

一度、起動しているInstanceをstopした後、再度、startしてから上記WordPressのサイトにブラウザでアクセスすると、適用しているthemeのstyle.cssがダウンロードできず、スタイルが崩れてしまうのです。また、管理者ページにアクセスしても、ページが表示されません。

Amazon EC2のMicro InstancesにWordPressをセットアップするより引用。

と同じ原因の事象です。

ホスト名が変わってしまうため、前回のWordPressの設定が、一部、正しくなくなってしまう

からです。

今回は、WordPressのデータベースを直接いじって、設定を変更することにしました。

WordPressの設定を一時的に変更する

変更する設定は、一般設定のURLの部分です。

該当するテーブルはwp_optionsです。

まず、sshでサーバにログインします。
次に、MySQLにログインします。

以下のSQLを実行したところ、

2件のレコードがヒットしました。option_nameが「site_url」のほうをアップデートしました。

これで、WordPressの管理者サイトにアクセスできるようになりました。

WordPressとプラグインのアップデート

管理者サイト「ダッシュボード」の「更新」メニューを選択します。

「WordPressの更新」ページから、WordPressのアップデートとバージョンアップされているプラグインを一式アップデートしました。

公開されているエントリを一通り動作確認します。

動作確認も終盤に差し掛かったところ、IE6でデザインがくずれているところを発見してしまいました。。。

当サイトで使用している、3カラムタイプのオリジナルテーマの右側サイドバーが段落ちしており、通常隠れているはずのプラグインの表示が、エントリの後半部分に見えてしまっています。

アップデートする前は、きちんと表示されていたはずなのに。。。

IE6ではCSSにposition:relativeの指定があるとoverflow:hiddenが効かない、というバグが原因のようです。
幅と高さが明示されていない要素へのoverflow:hidden;指定が完全に反映されない – CSSバグリスト

ということで、SyntaxHighlighter Evolved « Viper007Bond.comのCSSを一部、手直ししました。

●shThemeDefault.css
・変更前

.syntaxhighlighter {
    background-color: #FFFFFF !important;
    border: 1px solid #E0E0E0 !important;
    padding: 0 !important;
}

・変更後

.syntaxhighlighter {
    background-color: #FFFFFF !important;
    border: 1px solid #E0E0E0 !important;
    overflow: hidden;
    padding: 0 !important;
}

●shCore.css
・変更前

.syntaxhighlighter {
    margin: 1em 0 !important;
    padding: 1px !important;
    position: relative !important;
    width: 99% !important;
}

・変更後

.syntaxhighlighter {
    margin: 1em 0 !important;
    padding: 1px !important;
    position: static !important;
    width: 99% !important;
}

この修正でIE6のデザイン崩れに対処することができました。どうやら、アップデートする前に、SyntaxHighlighter Evolved « Viper007Bond.comのCSSに一部に手を入れていたところが、アップデート時に上書きされてしまったようです。プラグインの編集などで履歴が残り、履歴があればアップデート時に確認のメッセージが出るなどの機能があると素敵だと思いました。

Elastic IPを切り替える

動作確認も終了し、デザイン崩れも無事に修復できました。最後に、Elastic IPを切り替えます。本番サイト用に、Elastic IPでパブリックIPを1つ発行していますので、これを、割り当て中の本番環境のInstanceから、今回アップデートしたテスト系のInstanceに割り当てなおすと、テスト系のInstanceが自動的に本番環境に移行されているという作戦です。

このElastic IPを切り替えてる最中のみ、サイトにアクセスできない場合があるということになります。切り替えに、ほとんど時間はかかりませんので、ダウンタイムもほとんど発生しないということになります。

まず、割りあて中の設定を解除します。AWS Management Consoleで、左ペインの「Elastic IPs」を選択します。解除したい設定を選択して、「Disassosiate Address」ボタンをクリックすると、割り当て中の設定が解除されます。

続いて、テスト系のInstanceにElastic IPを割り当てます。IPを割り当てる手順は、通常の手順と同様です。Amazon EC2のMicro InstancesにWordPressをセットアップするを参考にしてください。

切り替えが完了したら、お役御免となったInstanceは停止しておくと良いと思います。

まとめ

このやり方なら、WordPressやプラグインのアップデートで不都合があっても、本番系に全く影響を与えることはありません。今回の、プラグインのアップデートでデザイン崩れが生じていた件も、本番系の画面が崩れることもありませんので、問題が発生してから対処するよりも、スマートに切り替えることが可能です。

また、今後バージョンアップする際にも、Root Device TypeがEBSのInstanceを停止せずにCreate Image（EBS AMI）する方法の内容も含めて、同様の手順を繰り返すことで、問題が生じた際も、表に出すことなく、かつ、最小限のダウンタイムでバージョンアップの運用を続けることができるので、非常に便利です。

発想次第、または、他のAWSのサービスと連携させることで、さらにスムーズに対応することも可能でしょう。

いつかは、もっと規模の大きいInstanceの運用にもチャレンジしてみたいと思います！

※ 当サイトでは、Micro InstancesをReserved Instancesで購入していますので、1時間当たりの課金量は$0.007です。ですが、こちらの料金体系は1インスタンスに対するものですので、途中、2つのInstanceを稼動させている際には、一方の課金量は、$0.02になります。切り替え後、また、1インスタンスでの運用に戻れば、1時間の課金量は$0.007になります。

株式会社ライブキャスト