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

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

2週間ほど BlueMix を使ってみました。今後も BlueMix 関連のブログエントリを書いていくつもりですが、一度この段階で感じたことなどまとめて書いてみます。なお過去のエントリはこちらです:
- 「BlueMix を使う」
- 「BlueMix のダッシュボードとデータベースを使う」
- 「BlueMix 上で PHP アプリを動かす」


まず「全体的によく出来てる」なあ、と感じました。BlueMix はウェブアプリケーションを「アプリケーション」、データベースなどの周辺機能を「サービス」として分けて提供しており、「アプリケーション」では Java や Node.js、Ruby、そして(標準機能ではないですが)PHP などを動かすことができます。また「サービス」は用意された選択肢から IBM 製品のものも、そうでないものも含めて選ぶだけで追加でき、アプリケーション側でそのサービスに接続するような記述をすることで連携して使える、というものになっています。

開発者視点でのウェブアプリケーション開発というのは、おおまかにはこの「アプリケーション」部分を作ることになるわけで、そこでは各種言語が使えるような柔軟性が提供されています。一方でデータストア等の「サービス」は選んで使うだけ、なので、ほとんど負担がありません。この分離方法は開発者視点でも非常に有用で理にかなっているな、と感じました。

自分の場合は Java アプリと PHP アプリを中心に、自分の手元にあるオンプレミスや IaaS 環境用のアプリがどの程度動くのか、動かすためにどの程度の変更が必要か、を調べながら使ってみましたが、「ウェブアプリに関してはほぼそのまま使える」という印象を持ちました。IaaS 向けのアプリが PaaS の環境で、それも war ファイルが war ファイルのまま(データベースの接続情報さえ変えれば)デプロイして動く、というのは感動すら覚えました。PaaS というと制約の多さや、IaaS/オンプレミス環境から移植性の難しさなどをイメージとして持ってしまいますが、BlueMix ではその辺りはかなり好印象でした。

もちろん、世の中のアプリすべてがウェブアプリケーションだけで完結しているわけではない(スケジュールエージェントやバッチ処理が必要なものもある)ことは理解しています。ただ少なくともウェブ部分に関しては BlueMix で動かすことはさほど高いハードルではないように感じています。


もうひとつ感じたことは「情報が意外と多い」ことです。これは BlueMix の情報が多いというよりは、そのベースとなっている CloudFoundry の情報として見つかることが多いという意味です。この辺りはオープンソースコミュニティの強みと言えますね。ただ現段階ではやはり見つかる情報は英語が多い、という現実があることも付け加えておきます。


一方で、2週間使ってみた上で???な点もあります。まずサービスの中身がよく分からない、という点を挙げたいです。例えば MySQL サーバーを使いたければサービスから MySQL を選ぶだけでいい、確かにその通りです。でもこうして作成された MySQL サーバーのスペックやバックアップ体制、デフォルトで用意されるデータベースの属性(デフォルト言語は UTF-8 になっているのだろうか??など)、、、簡単なのは悪いことではないのですが、簡略化されすぎていて、良くも悪くもブラックボックスに隠れちゃってる(それでいて情報がない)点が多いと思いました。この辺りは CloudFoundry というよりは BlueMix の運用体制に関わる部分なので、IBM からの情報として開示してほしい所ではあります。

あと、現状はオープンベータとして開発者中心に無料で自由に使える素晴らしい環境を提供いただいているのですが、このベータプログラムが終了した後の、実際に商用サービスとして始まる際の情報が少なすぎると感じます。要は「このオープンベータプログラムはいつまで使えるの」「商用版を使うのにいくらかかるの?」ということです。

ちなみに本家 CloudFoundry では「使ったサーバーのメモリ量」をベースに課金されます。例えば 512MB のメモリを搭載したサーバー2台と 1GB のメモリを搭載したサーバー1台を使った場合は 2GB 分の課金がされる、という具合。CPU や I/O、ネットワーク、そして中で使った OS、ソフトウェアへの課金はありません。ある意味でシンプルな課金体系になっています。

※なお、CloudFoundry の現在の具体的な料金は $0.03 /GB/Hour (1GB を1時間使うと3セント)です:
 http://dreamand.me/cloud/cloudfoundry-v2-review/

 仮にメモリ 1GB のサーバー1台を30日間使う場合であれば $0.03 * 24 * 30 = $21.6 という計算になります。


これが BlueMix ではどうなるのでしょう? CloudFoundry と同じような体系になることも想像できますが、そうでない体系になる可能性もあります。またサービスで提供されている機能の中には IBM の商用ソフトウェアも含まれており、これらが無料で提供されるとは考えにくいのですが、ではどういった料金(体系)になるのか? BlueMix には使いやすいダッシュボードや豊富なサービスによる差別化もあると思うのですが、とにかく現状は価格に関する情報が少なすぎる(というか皆無)ので、その辺りの情報が欲しいところではあります。


最後に、今僕自身が「日本で CloudFoundry に詳しい会社ってどこだろう?」と考えた時、真っ先に思いつくのは実際に社内で活用していて、ウェブに資料も多く公開している楽天です。次が実際にサービスを展開しているNTTコミュニケーションズ。残念ながら、現時点では日本アイ・ビー・エムという印象は薄いです。

今後、BlueMix を展開していく中で、日本アイ・ビー・エムがこの国内2強に割って入るような会社として認識されるような存在になってほしい、そのためにもまだ充分とはいえない日本人ユーザー向け情報や資料を BlueMix を推進していく中でどんどん充実させていってほしい、と感じています。













(2016/Feb/08 追記)
ここに書かれている内容のうち、特に phpMyAdmin を導入する部分の内容が古くなってしまったので、書き直しました:

Bluemix で phpMyAdmin を動かす



BlueMix に挑戦シリーズ(?)の第3回目です。以前のエントリはこちら:
「BlueMix を使う」
「BlueMix のダッシュボードとサービスを使う」


今回は BlueMix 上で PHP アプリを動かすことに挑戦してみます。「あ、自分は PHP 使わないので結構です」という方も少なからずいると思いますが、PHP を動かすことだけが目的ではないので、もう少しお付き合いください。

前回のエントリでは BlueMix 上にデータベースサーバーを加えて、アプリケーションサーバーと接続して利用できるようにしました。一般的なアプリサーバー <-> DBサーバーの2層トポロジーが作れたことになります。

ただし、この段階では「単に繋がっただけ」です。繋がっているのでアプリケーションサーバーからDBサーバーの情報を取り出したり、作成/更新したりはできますが、少なくとも現時点ではDBの中身は(テーブル定義も含めて)空です。アプリケーション側から JDBC などで SQL を使うことはできるので、"create table .." でテーブル定義を指定することはできるし、"insert into .." してデータベース/テーブルの初期状態を作ることもできますが、裏を返せばその辺りの準備がまだ全然できていない状態で単に繋がっている、ということです。

この辺りは開発者や開発会社のポリシーなどにもよるのかもしれませんが、僕個人の周囲ではこの「データベースの初期化」の処理はコマンドラインツールを使って自分の PC からデータベースサーバーに接続し、ダンプからまとめてドーン!とインポート、という方式を取ることが多かったりします。この BlueMix 環境でも同様にして初期化すればいいや、と思っていましたが、セキュリティ上の制約なのか、どうやら BlueMix 外の環境からは BlueMix 上のデータベースサーバー(少なくとも MySQL と mongoDB)への接続は許可されていないようです。ということは自分の端末のコマンドラインからインポート、という方法は使えませんね。。。うーん。。。
2014032701


そこで思いついた方法が「BlueMix 内でデータベースの管理アプリを動かしてしまう」という方法です:
2014032702

BlueMix 内にもう一台アプリケーションサーバー(上記例だと「DB管理用サーバー」と書かれた部分)を新たに用意して、そこにはデータベース(上記例だと MySQL)を管理するためのウェブアプリケーション(例えば phpMyAdmin)を導入します。こうすることで自分の PC から管理用サーバーへはウェブブラウザで、管理用サーバーからDBサーバーへはネイティブのドライバでそれぞれ接続する形になります。そしてこの管理アプリケーションの機能を経由してテーブルを作成したり、初期データをまとめてインポートしたり、といったメンテナンス作業ができるようにする、というアイデアです。アイデアというよりも普段普通にこういう構成を作ることも珍しくありませんよね(それが許可されていれば、ですが)。

ただし、この方法にも1つ問題があります。DBの種類にもよるのでしょうが、MySQL では上記のように有名な管理アプリとして phpMyAdmin があり、今回もこれを導入するつもりですが、phpMyAdmin を使うにはその名の通り PHP 環境が必要です(正確には PHP + HTTPD の環境)。同様にして mongoDB の管理アプリの1つに phpMoAdmin がありますが、こちらも PHP 環境が前提です。特にオープンソース系データベースサービスではその管理ツールが PHP で書かれていることが多いこともあって、BlueMix 上でデータベースサービスを使おうとすると、管理目的でこれらの PHP アプリを動かしたい、という需要はそれなりにあるのでは、と思っています。

一方、BlueMix の標準アプリケーションサーバーには Java と Ruby が用意されていますが、残念ながら PHP ベースのものは用意されていません(クローズドベータの頃は存在していた、という噂も聞いていますが・・)。制約の多い PaaS 環境で、Java アプリケーションサーバーに後から PHP や PHP アプリだけを追加する、というのも難しそうです。うーん、この方法も諦めざるをえないのでしょうか・・・


・・・というところで今回のブログエントリの冒頭部分に戻ります。要は各種 PHP アプリも動かしてみたいというわけではなく、DB サーバーのメンテナンス用アプリケーションとしての PHP + HTTP 環境が使えないだろうか、という背景があったのでした。

こうなると頼りになるのは IBM developerWorks、英語版のコミュニティを探してるとやはり見つかりました。しかもご丁寧なことに多バイト言語にも対応した PHP モジュールが用意されているようです。もう至れり尽くせり、これを使わせていただきましょう!
https://www.ibmdw.net/answers/questions/8925/how-do-i-connect-to-my-bluemix-mysql-service-to-setup-mysql-database/


導入の手順としてはこんな感じです:
前提としてまず cf ツールの動作環境は用意できていることとします。分からない方は以前のエントリを参照ください。
加えて、BlueMix 上に専用のアプリケーションサーバーを1つ作っておきます(種類はなんでもいいです)。名前は kkimura2、ホスト名は kkimura2.ng.bluemix.net としたと仮定します(この辺りの詳しい手順についても以前のブログエントリを参照してください)。自分で作った(る)環境に合わせて適宜読み変えてください。これからこのサーバーに PHP + HTTPD モジュールを導入してゆきます:
2014032703



作成したサーバーを稼働中の(管理したい) MySQL サーバーに紐づけます。まずは OVERVIEW に移ってから Services 欄の "Add existing service" をクリックします:
2014032704


どのサービスをアプリケーションサーバーに紐づけるかを設定します。この例では MySQL しか使っていないので1つしか表示されていませんが、目的のサービスを選択して OK をクリックします:
2014032705


OVERVIEW 画面に戻り、アプリケーションサーバーに MySQL サービスが紐づけられたことを確認します。この状態で紐付けられた MySQL サーバーへの接続情報を確認しましょう。左ペインの "LIBERTY FOR JAVA" をクリックします:
2014032706


一番下の Environment Variables 欄の VCAP_SERVICES の値を参照して、MySQL サーバーへ接続するための情報を確認してメモしておきます。必要なのは name(DB名)、hostname、port、username、そして password あたりです:
2014032707



ここからは cf ツールをセットアップした環境での作業になります。最初に専用のディレクトリを1つ新規に作ります。新規に作成する必要はありませんが、空のディレクトリを用意してください(ここでは /tmp/php というディレクトリを作りました):
# cd /tmp
# mkdir php
# cd php


用意した空のディレクトリに PHP のモジュールをまとめてコピーします。イメージとしては、このディレクトリがドキュメントルートになるので、ドキュメントルート直下に必要なファイルをすべて用意する、という感じ。今回は phpMyAdmin の最新版をダウンロード&展開&ディレクトリリネームして、phpMyAdmin というディレクトリの中に一通りのファイルが展開されているようにしました(phpMyAdmin/config.sample.inc.php というファイルが存在しているようにします):
# pwd
/tmp/php
# ls
phpMyAdmin
# ls phpMyAdmin
CONTRIBUTING.md
ChangeLog
README
  :
  :
(phpMyAdmin の構成ファイル)


PHP ファイルに DB 接続情報を設定します。phpMyAdmin の場合、phpMyAdmin 以下に config.sample.inc.php というテキストファイルがあるのでこれを config.inc.php という名前でコピーします:
# cd phpMyAdmin
# cp config.sample.inc.php config.inc.php


そして先ほどメモした内容を使ってその中身を編集します(余談ですが BlueMix の MySQL ってポート 3307 番で稼働してるんですね・・):
# vi config.inc.php

$cfg['Servers'][$i]['host'] = '(MySQL サーバーのIPアドレス)'; ←'localhost' から変更
$cfg['Servers'][$i]['port'] = '3307(MySQL サーバーのポート番号)'; ←この行を追加

もし phpMyAdmin 以外に導入したい PHP アプリがあれば、同様にこのディレクトリに入れておきます(そして必要であれば同様に接続先 MySQL サーバーの設定をしておきます)。自分の場合は PHP + MySQL の環境で動く WordPress も使いたかったので、同じディレクトリ内に wp というディレクトリを作成して、DB 設定ファイル(wp/wp-config.php)も用意&編集して入れておきました。この辺りは WordPress の一般的な導入手順の話なので、興味があればググってみてください。

で、自分の場合はもともと空だったディレクトリに phpMyAdmin と wp という2つのサブディレクトリが作られた状態になっています:
# pwd
/tmp/php
# ls
phpMyAdmin  wp


ではこのディレクトリをドキュメントルートとして PHP サーバーに(PHPサーバーごと)デプロイします。Cloud Foundry のコミュニティで用意された PHP サーバー用の BuildPack (の github リポジトリ)と、デプロイ先のアプリケーションサーバー名を指定して、次のように入力します:
# cf push -b https://github.com/dmikusa-pivotal/cf-php-build-pack.git kkimura2
Updating app kkimura2 in org (IBM ID) / space dev as (IBM ID)
OK

Uploading kkimura2...
Uploading from: /tmp/php
17M, 2296 files
  :
  :
OK

requested state: started
instances: 1/1
usage: 512M x 1 instances
urls: kkimura2.ng.bluemix.net

     state     since                    cpu    memory          disk
#0   running   2014-03-27 05:39:23 PM   0.0%   12.7M of 512M   112.2M of 1G

このコマンドでは -b オプションでベースとなる機能(この例では PHP と HTTPD)のコピー元を指定しており、そこに用意されたモジュールと定義されたスクリプトに従って PHP サーバーイメージが作られていきます。Cloud Foundry ではこういったサーバーを Build Pack というツールで作成することができるので、こうしたコミュニティによる機能拡張もできるようになっているのでした。Build Pack についてはまた別の機会で触れたいと思っています。

これで PHP のアプリケーションサーバーが作られ、起動し、そのドキュメントルートには phpMyAdmin と wp(WordPress)が用意された状態になっているはずです。

では早速 phpMyAdmin を使ってみましょう。http://ホスト名/phpMyAdmin/ にブラウザでアクセスしてみます:
2014032708


おお! で、これもメモしたユーザー名とパスワードを指定してログインしてみると、、、
2014032709

 
おおお!!! これでこの画面から MySQL のテーブルを作ったり、データを CSV からインポートしたり、逆にエクスポートしたり・・・なんて操作も可能になりました。個人的に慣れたコマンドラインのインターフェースとは違いますが、GUI はやはり便利ですね。

またもう一つの PHP アプリである WordPress にもアクセス(http://ホスト名/wp/)してみました。こちらもちゃんと動いてますね:
2014032710


BlueMix 環境での DB 管理方法を調べていたら、PHP アプリの動かし方まで理解できました~、の巻♪
 

久しぶりの 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 が使えます。








 

このページのトップヘ