12月 232011
 

 ここ5年ほど MovableType を使っていたが、最近は WordPress のほうがメジャーになってきた。当初は静的化される MovableType に魅力を感じていたが、毎度の再構築が面倒くさいこともあって WordPress に移行することにした。

 MovableType と WordPress は、運用するシステム的に以下の違いがある。

  • MovableType
    • Perl
    • CGI または mod_perl, FastCGI
    • 記事は基本的に静的 HTML で閲覧負荷は低いが、PHP スクリプトなどとしても出力できる。記事の追加・修正のたびに再構築される。
  • WordPress
    • PHP
    • mod_php または FastCGI
    • 記事はアクセスごとに動的生成。ただし、プラグインでキャッシュ可能。

 MovableType 時代は主にデータベースサーバとして使っているサーバに Apache をインストールしてそこで CGI として動作させていたが、DB サーバは LAN 内にあるので、ルータで動作している Varnish でリバースプロクシしていた。

 今回 WordPress に移行するに当たって、アプリケーションサーバと DB を別マシンにするために KVM 上で動く仮想環境に移行した。DB サーバへのアクセスが LAN 内のトラフィックの影響を受けないように、仮想環境と DB との接続は LAN とは別のノードになっている。

 また、単純に Apache + mod_php も面白くないので FastCGI で動作させてみることにする。最近のトレンドでは nginx + spawn_fcgi が流行のようだが、spawn_fcgi だと php-cgi が死んだときにリスポーンせずにサービスが止まってしまう現象があったため、PHP 5.4.0 RC2 から正式にマージされた PHP-FPM を試してみた。

 WordPress に移行するに当たって記事などのデータそのものはエクスポート→インポートで問題ないが、その他いくつかの問題点が発生する。今回は以下の問題点があった。

  1. そもそも本当に記事を移行できるのか?
  2. URL の問題。
    • パーマリンクは MovableType の日付 + ファイル名を引き継いでいいのか?
    • RSS フィードの UR Lが変わってしまう。
    • カテゴリなど、中層のURLは?
    • 画像などのURLは?
  3. テンプレートに埋め込まれた Google Analytics や Adsense をどうするのか?
  4. 移行手順をどうするのか?
  5. どうせならモバイル対応(ry
  6. nginx 固有の問題

 考えていても時間だけが無駄になるので、まずはサブドメインを切ってそこに WordPress 環境を構築することにした。ドメイン以外は本番と同じ構成とし、問題ないと判断できればすぐに移行できるようにしておく。移行は、WordPress の設定でドメインを本番用に変更した上で、リバースプロクシが向いているバックエンドを切り替えればよい。

 まず1.については、記事とコメントについては問題なく移行ができた。ただ、問題はどうしても2.のURLの問題になる。MovableType のパーマリンク構造を引き継ぐことは可能だが、せっかくなのにもったいないと思う。今回、2008年に一度 blog データが消えていることもあって 58 エントリしかなかったので、力業で rewrite ルールを書くことにした。RSS フィードの URL についても rewrite すれば問題ない。

 Apache と nginx ではシンタックスは違うものの、ほぼ同じように URL の rewrite が可能になる。たとえば、MovableType 時代の atom.xml のルールは

rewrite ^/atom.xml http://$host/feed/ permanent;

となる。このようにして、ほか 58 記事分のパーマリンクの rewrite ルールを書けばよい。ただし、実際には面倒なので記事タイトルをキーとしてスクリプトで処理している。
 画像については、旧画像の URL については /oldies 以下に、サムネイルについては旧 URL に配置することとし、MovableType 環境からファイルをコピーすることで対応した。画像も旧 URL を踏襲したかったが、if のネストや複数条件を書けない nginx 側の仕様もあって面倒なのでこういう対応とした。記事側も修正しなければならないが、これは WordPress にインポートする前にテキストエディタで置換しておく。

 3., 5., 6.については、WordPress の充実したプラグインで置き換えることで対応した。スマートフォン環境で GoogleAdsense の影響で若干崩れているが、大きな問題にはならない感じなので見なかったことにしている。

 最後の nginx 固有の問題というのは、やはり Apache と設定ファイルのシンタックスが大きく違うことが原因。WordPress のパーマリンクを実現するためには rewrite ルールの追加が必須となるが、これは Apache mod_rewrite 形式で提供されるので、nginx 形式に書き換える必要がある。これは Google 先生に聞けばすぐ

if (!-e $request_filename) {
    rewrite ^.+?(/wp-.*) $1 last;
    rewrite ^.+?(/.*\.php)$ $1 last;
    rewrite ^ /index.php last;
}

と分かる。

 あとは、Apache で言うところの mod_rpaf 的なものが必要になる。これがないとアクセスログに記録される IP アドレスがすべてリバースプロクシの LAN 側 IP アドレスになってしまう。Apache では mod_rpaf といった外部モジュールが必要になるが、後発の nginx では標準的にサポートされている。

set_real_ip_from 192.168.1.1;
real_ip_header X-Forwarded-For;

これで、192.168.1.1 からのアクセスは、X-Real-IP ヘッダで REMOTE_ADDR が置き換えられる。なお、Apache の場合はデフォルトで本来の IP アドレスが X-Forwarded-For ヘッダで送られるので問題ないが、Varnish は VCL で明示的に指定する必要がある。これは、vcl_recv などで

req.http.X-Forwarded-For = client.ip;

とする。

 最後に、www.damelog.com や blog.damelog.com といったサブドメインが重複コンテンツとして Google に判断されるので、これを damelog.com に統一する設定を書く。

server_name *.damelog.com;
~
if ($host ~ "\.damelog\.com$") {
    rewrite ^ http://damelog.com$request_uri permanent;
}

 これで、DNS にあるサブドメインすべてが damelog.com にリダイレクトされる。

 こんな感じで WordPress への移行は完了。仮想環境のセットアップも含めた実工数はだいたい 10 時間くらいだろうか。仮想環境のテンプレートを用意してあることもあるが、記事数が少ないので片手間レベルでできる作業だった。


Comments

comments

Powered by Facebook Comments