まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

久しぶりの WordPress ネタです。

WordPress をサーバーごと引っ越しする場合、大まかな手順としてはこんな感じになると思います:
(1) 引っ越し先サーバーに PHP, MySQL, HTTPD を導入
(2) 引っ越し先サーバーに MySQL 用のデータベースを作成&アクセスユーザーとパスワードを作成
(3) 引っ越し前サーバーの WordPress ディレクトリをまるごと引っ越し先サーバーにコピー
(4) 引っ越し先サーバーの WordPress の設定ファイルを更新
(5) 引っ越し前サーバーから MySQL 用データベースをまるごとエクスポート
(6) 引っ越し後サーバーに (5) のデータをまるごとインポート
(7) データ調整

(1) は引っ越し先サーバーへのミドルウェアのインストールです。Linux 環境であれば yum で簡単にできちゃうと思っています:
# yum -y install mysql-server php php-mbstring php-mysql httpd

この後の手順で WordPress の環境をディレクトリまるごとコピーして引っ越しすることを想定しているので、理想を言えば PHP や MySQL などのバージョンも合わせておければ確実です。逆を言えば、もしうまく動かなかった場合はミドルウェアのバージョン差異を疑ってみてください。ま、よほど昔の環境からの移行、とかでなければ大抵は大丈夫だと思いますが、、、


(2) は引っ越し先サーバー側の MySQL の設定です。DB 名を wp_db、ユーザー名を wp_user、パスワードを wp_pass にするのであればこんな感じ:
# mysql -u root -p(パスワード)
> create database wp_db default character set utf8;
> grant all privileges on wp_db.* to wp_user@localhost identified by 'wp_pass' with grant option;
> quit
(3) は WordPress そのものをファイルシステムのレベルでコピーしちゃいましょう、ということです。引っ越し元の /var/www/html/wordpress に WordPress が導入されていて、それを引っ越し先の同じディレクトリに移動させるのであればこんな感じでしょうか:
(転送元での作業)
# cd /var/www/html
# zip -r wp.zip wordpress/ 
  (この結果できあがったファイル wp.zip を引っ越し先サーバーの /tmp とかに転送しておく)

(転送先での作業)
# cd /var/www/html
# unzip /tmp/wp.zip

(4) は新しい WordPress の設定ファイルの更新です。上記例であれば wordpress/wp-config.php というファイルが設定ファイルなので、これを新しい環境用に(DB接続情報などを)指定します:

ここまでの作業で WordPress 本体の引っ越しは(ほぼ)完了しています。ただ引っ越し先にはデータの中身が全く入っていない状態なので、それを引っ越し前のサーバーから移動させる作業が残っています。(5), (6) がその作業になります。

(5) は引っ越し前サーバーのデータをまとめて取り出す、という作業です。WordPress のデータが入っているデータベースをテーブル設計からまとめてダンプすることになるので、引っ越し前のデータベース名/ユーザー名/パスワードがそれぞれ wp_db / wp_user / wp_pass だったとして、ダンプの出力先ファイルを wp.sql とすると、こんな感じのコマンドを実行することになります。
# mysqldump -u wp_user -pwp_pass wp_db > wp.sql

(6) は (5) で取り出したデータをまとめて (2) で作った引っ越し先のデータベースに入れる、という作業です。(5) で作成した wp.sql を引っ越し先データベースに転送してからこんな感じのコマンドを実行します:
# mysql -u wp_user -pwp_pass wp_db
> source wp.sql

これでデータベースの中身の引っ越しも終わりました。WordPress ディレクトリごとコピーしているのでプラグイン類もそのまま移行されているし、カスタムフィールド等を使っていたとしてもデータベースまるごと移行しているので、そのカスタムデータも含めて移行されているはずです。事実、ここまでの作業でもう引っ越し先の WordPress にアクセスすればデータが参照できる状態になっているはずです。


でも実はここからが本題です。WordPress も、データベースも、どちらも引っ越し前のものを引っ越し後の環境に移動できました。でもこれだけでは足りないのです。それが (7) の作業になります。

実は WordPress は自分自身の動作環境に関わる設定を上記 (4) の設定ファイル以外にデータベース内にも格納しています。その内容は当然引っ越し前のものであり、それをそのまま引っ越し後の環境で使おうとしても正しい設定ではないため、想定外の動作を引き起こす可能性があります。それを調整する作業が必要です。

具体的には、WordPress が(引っ越し前のサーバーで)最初にセットアップした時に収集した情報が、動作のための情報として wp_options テーブル内に格納されています。その情報には「自分自身のURL」が含まれていて、その内容は当然引っ越し前のサーバーの URL になっています。ということは WordPress が自分自身の URL を調べて戻ろうとすると、引っ越し前のサーバーの URL に戻ってしまう、といった動作を起こしてしまいかねないのでした。そういったことが起こらないよう、データベース内の該当データを調整する必要があります。

そのため、最後の (7) の作業としては上記のような引っ越し前サーバーの情報を新しい引っ越し先サーバーの情報に書き換える、ということになります。

具体的な作業としては、引っ越し前サーバーのホスト名が www1.host.co.jp、引っ越し後サーバーのホスト名が www2.host.com だったとすると、引っ越し後の WordPress の wp_options テーブルには(ホスト名が www2.host.com であるにも関わらず)次のような引っ越し前サーバーの情報が格納されているはずです:
# mysql -u wp_user -pwp_pass wp_db
> select option_name, optoin_value from wp_options where option_name = 'siteurl' or option_name  = 'home';
+-------------+-----------------------------------+
| option_name | option_value |
+-------------+-----------------------------------+
| home | http://www1.host.co.jp/wordpress/ |
| siteurl | http://www1.host.co.jp/wordpress/ |
+-------------+-----------------------------------+

これらを新しい引っ越し後サーバーの情報に書き換える必要があります。SQL だとこんな感じでしょうか:
# mysql -u wp_user -pwp_pass wp_db
> update wp_options set option_value = 'http://www2.host.com/wordpress/' where option_name = 'home' or option_name = 'siteurl';
> select option_name, optoin_value from wp_options where option_name = 'siteurl' or option_name  = 'home';
+-------------+---------------------------------+
| option_name | option_value |
+-------------+---------------------------------+
| home | http://www2.host.com/wordpress/ |
| siteurl | http://www2.host.com/wordpress/ |
+-------------+---------------------------------+

これで WordPress のオプションデータの調整もできました。安心して引っ越し先サーバーで WordPress が使えます。








 

ネットワーク(もしかして Facebook ??)の調子があまりよくない時に気付いた小ネタです。
Facebook を PC のブラウザでページの一番下までスクロールした時の様子。

んー??? こんな感じがしばらく続いて・・・
2014032601

 
で、しばらく待つと中身が入ってこんな感じに(加藤さん、おいしそうな画像使わせていただきました):
2014032602
 

一番下までスクロールして、「次のデータを取りに行こう」とした段階で空のフォームだけは先に描画しちゃってるんですね。で、AJAX とかで中身が取れたら埋める、と。

普段は AJAX で取得するまでが一瞬だと思うので、こんな順序で描画されていることに気付けません。たまたまネットワークの調子が悪かったか Facebook からのリターンが遅れていたことで Facebook 流(?)の方法に気付けました。ラッキー!


 

「IBM 版の Cloud Foundry」(という表現でいいのでしょうか?)である BlueMix のレポート第二弾です。
前回のはこちら: 「BlueMix を使う」

前回は BlueMix のアカウントを取って、Java アプリケーションサーバーを1つ作って、war ファイルをデプロイする、という手順を紹介しました。IaaS 環境用の war ファイルがそのまま動く、というのは PaaS であることを考えるとなかなか凄いな・・ という印象でした。

今回は前回使わなかったデータベースサーバーを作ってつなげてみる、という所を紹介します。
が、そこでの手順に関係していることもあって、その前にもう少しダッシュボードの説明をさせてください。

前回紹介した作業までを行った状態で、再度 BlueMix にログインした時の様子がこんな感じになると思います。作成した Java アプリケーションサーバーが APPS というところに1つ追加されているのがわかります。この APPS をクリックします:
2014032601


APPS が展開されて、現在この環境で動かしているアプリケーションサーバーの一覧(といっても今は1つだけですけど)が表示されます。前回作成したアプリケーションサーバーの名前は "kkimura1" にしたので、そのサーバーが表示されています。ここでも再度アプリケーションサーバー名(この例だと "kkimura1")をクリックします:
2014032602


"kkimura1" アプリケーションサーバーの現在の状態が表示されました。App Runtime 欄でランタイムは "Liberty for Java" という Java アプリケーションサーバーが使われています。また Services 欄にはまだ何のサービスも紐づいていないことがわかります。ここでアプリケーションサーバーの状態を更に細かく見るため、左ペインの "LIBERTY FOR JAVA" と書かれた箇所をクリックします:
2014032603


現在のアプリケーションサーバーの状態が表示されました。Resources 欄を見ると、現在のインスタンス数は1、メモリ上限は 512MB で稼働していることがわかります。また Instance Details 欄では現在の CPU 稼働率が 0.3%、メモリ利用量は 90.8MB であることもわかります:
2014032604


実はインスタンス数とメモリ上限はこの画面からダイナミックに変更することができます。メモリが足りなくなってきたら Memory Quota を変更して増やしたり(或いは減らしたり)、CPU が厳しくなってきたら Instances を増やして負荷分散したり、ということがここから簡単にできてしまうのでした。これは超便利!

また更に画面下部を見ると、Environment Variables と書かれた欄があります。ここでアプリケーションサーバーの各種環境変数を見ることができます:
2014032605


この状態では VCAP_SERVICES という環境変数の中身が empty と報告されています。実はこの環境変数はアプリケーションサーバーがデータベースなどのサービスと紐付けられた時に、その接続情報が格納される変数なのでした。この段階では(まだ何のサービスとも繋がっていないため)中身が空のままになっている、ということです。


ではこのアプリケーションサーバー用にデータベースサーバーを1つ起動させてみましょう。BlueMix ではデータベースは「サービス」の1つとして提供されています。そこでダッシュボード画面に戻り、左ペインの SERVICES と書かれた箇所をクリックします:
2014032606


すると選択できる各種サービスの一覧が表示されます。"BLUAcceleration" ってのが DB2 だよな。後は・・・なんとなくわかるようなわからないような IBM 製サービス("IBM Created")が並んでいます:
2014032608


少し下の方をみると IBM 製ではないサービス("IBM Certified" や "Community")も並んでいます。データベースだけでなく、メッセージキューやジオコーディング、そして電話/SMS連携の Twilio なんかも選ぶことができるようです。 色々試してみたいところですが、とりあえずは1つデータベースを選びます。得意なのを選びましょうか、自分の場合は "MySQL" を選んでみました:
2014032609


確認画面が表示されるので "ADD TO APPLICATION" をクリックします:
2014032610


そして、この MySQL サービスをどのアプリケーションサーバーと紐づけるか聞かれます。この段階ではどことも紐づけなくても構いません(その場合は単独で稼働する MySQL サーバーになります)が、上述の環境変数の確認をしたいので最初に作ったアプリケーションサーバーを選ぶことにします。これでこの MySQL サーバーが Java アプリケーションサーバーと紐づけられたことになります。最後に "CREATE" をクリックして起動します:
2014032611


ダッシュボード画面に戻ると、SERVICES 欄に (1) という数字が表示されているはずです。また MySQL サーバーが SERVICES から確認できるはずです:
2014032612


ダッシュボードの ALL を見ると、Java アプリケーションサーバーと MySQL サーバーの2つが確認できます。また Java アプリケーションサーバーに紐づけられたサービスとして MySQL のアイコンが表示されているはずです:
2014032613


さて、この状態で改めて上述の Java アプリケーションサーバーの Environment Variables 欄にあるVCAP_SERVICES の値を確認してみましょう。JSON フォーマットでこんな感じの値が表示されるはずです:
2014032614

 
これが Java アプリケーションサーバーからみた MySQL サーバーの接続情報になっています。MySQL サーバーのホスト名(IP アドレス)が hostname 値、ポート番号が port 値、データベース名が name 値、 ユーザーIDが username 値、そしてパスワードが password 値にそれぞれ格納され、1つの JSON にまとまっています。

アプリケーションサーバーからは、これらの情報をあらかじめ確認した上で(ソースコード内に)接続のための情報を記述すればデータベース接続ができます。ただよりスマートに以下のような方法も考えられます:
(1) アプリケーション側でまず VCAP_SERVICE を確認し、 
(2) 中身(JSON)が入っていた場合は、JSON をデコードして接続のための情報を動的に取り出してデータベースに接続する
(3) VCAP_SERVICE に値が設定されていなかった場合は(それは BlueMix 環境ではないことを意味するので)通常の IaaS やオンプレ環境として接続先のデータベース情報を取得する 

このようにすると BlueMix 環境用と、BlueMix でない環境用それぞれで接続先データベースを都合いい方法で取得/設定することができるようになると思われます。war/ear ファイルがそのまま動くような環境だからこそ、こういう方法で接続先データベースも分けられるのは(その情報をハードコーディングする必要もなくなるので)便利ですね。

・・・ところで、Java で JSON 使う時の便利なライブラリをどなたかご存知ないでしょうか? いくつか知ってるんですが、どれも「帯に短し・・・」的な感じで、「これっ!」ってのがないんですよね。。



 

このページのトップヘ