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

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

2015年10月

IBM Bluemix から提供されている各種 API の中に Insights for Twitter サービスがあります:
2015102901


Twitter のつぶやきデータに、IBM が付与した感情やユーザーの推定属性をデータベース化して、検索 API として提供しているものです。(Twitter 社が提供している)標準 API ではできないような検索絞り込みが出来たり、標準 API では制限されているような、時間あたり API 利用回数制約もなく使える、という特徴があります。

この Insights for Twitter API には2つの価格プランがあります:
2015102902


1つは Free プランで、もう1つは Entry プランです。上の図を見ると、Free プランは無料で月に500万件までのツイートを取得可能、Entry プランは月額21万円で月に100万件のツイートを取得可能、と書かれているように見えます。。

「え? 逆じゃないの??」

と思うかもしれませんが、実は正しいのです。この価格について、もう少しきちんと説明します。

実はこの2つのプランは取得できるデータに違いがあります。Free プランで取得できるデータ源は decahose と呼ばれているもので、ツイートデータ全体の約10分の1が母集団になっています(つまり、検索データベースの中に含まれていないツイートも多い)。標準の Twitter API を一般の開発者が使う場合もこの decahose を対象にツイートデータを取得できる、というものです。一方 Entry プランで取得できるデータ源は firehose と呼ばれる全ツイートデータです。標準 Twitter API を使う一般の開発者がアクセスできるものではなく、限られた環境下でのみ提供されているものです。Bluemix の Insights for Twitter API の Entry プランを申し込んでいただいた場合は、そこにアクセスできるようになる、ということになります:

Free プラン比較Entry プラン
無料料金月額21万円
500万1ヶ月間に取得できるレコード量100万
decahose
全ツイートの10分の1
データ源firehose
全ツイート


Free プランで取得できるデータは、オリジナルの Twitter API で取得できるデータと比べてデータ源は変わりません。ただ IBM のインサイト情報が付与されており、感情やユーザー属性を指定した便利な検索が可能になっています。
一方、Entry プランを使うと便利な検索機能に加え、一般の開発者権限ではアクセスすることのできない firehose にアクセスすることができる(より実態に近いデータを集めることができる)、という点が大きな違いと言えます。


・・・って、軽く書いちゃったけど、firehose にアクセスできる環境が入手できるって凄いことだよね。しかも体験期間中であれば無料ってこと? (O.O ;


IBM Bluemix のサービスの中には IBM のリレーショナルデータベースである DB2 が3つ用意されています:
2015102201

これらの中身はいずれも DB2 ですが、サービスとしては同じではありません。これらの違いについて、簡単に紹介します。


まず "SQL Database" です。これは DB2 の標準機能を DBaaS として提供するものです(JSON ストアなど、ライセンス製品では提供されている一部の機能は使えません)。IBM のクラウド上に指定されたスペックの DB2 インスタンスが用意され、IBM が管理する、というものになります:
2015102202


次に "DB2 on Cloud" です。こちらも DB2 の機能を IBM のクラウド(SoftLayer)上にインスタンスを作成して提供するものです。前者の "SQL Database" との大きな違いは利用者が(SSH を使ってサーバーにログインして)管理するという点にあります:
2015102203


最後は "dashDB" です。これはライセンス製品名でいうと "DB2 BLU Accleration" という上位エディションにあたるもので、カラムストアや R 言語エンジンといった統計処理を行うための機能が提供された DB2 、という位置付けになります:
2015102204


これらの違いをまとめるとこのような感じになるでしょうか:
 SQL DatabaseDB2 on ClouddashDB
提供ソフトウェアDB2 Enterprise ServerDB2 Advanced Workgroup ServerDB2 BLU Acceleration
提供形態DBaaSクラウドDBaaS
管理者IBM利用者IBM
用途データの格納
クエリーによる取り出し/更新
データの格納
クエリーによる取り出し/更新
データの格納
統計計算


なので、用途が少しずつですが目的としては明らかに違う、ということがお分かりいただけると思います。DB2 サーバーとしてはいずれもクラウド上にあるものですが、管理の有無や用途などが異なっているので、「どれがいいか?」ではなく、「どういう要件で何をするのか/したいのか?」を基準に考えていく必要があります(場合によっては複数組み合わせることもあります)。


IBM Bluemix には、IBM の中の人しかアクセスできない環境があります。いわゆる「ステージング環境」で、安定運用よりも実験的な意味合いの強い環境です。中身はパブリックに公開している API に加え、今後公開予定の API が隠れていたりします。

で、その中に面白そうな API があったので、予告編的な意味合いでチラ見せします(注 2015/Oct/28 正式サービス化されました)。それがこの "Insights for Weather" 、天気情報の API です:
2015102101


実はこれ、全くの新しい情報ではなく、今年の3月に IBM と The Weather Company 社とのビジネスパートナーシップが提携されてから進められてきた成果の1つでもあります:
http://www.ibm.com/big-data/us/en/big-data-and-analytics/ibmandweather.html

こちらは英語の開発者ブログですが、この中では「Bluemix カタログからの提供も予定されている」と言及されていました。このプロジェクトが着々と進んでいる、ということだと思っています:
https://developer.ibm.com/bluemix/2015/03/31/weather-means-business/


現状で(このステージング環境上で)提供されている API は、大きく「予報」と「状況」の2つの情報に関するものです。API では位置(緯度、経度)言語を指定して、例えば「状況」を調べる API であれば、
https://(username):(password)@twcservice.mybluemix.net/api/weather/v2/observations/current?geocode=35.69,139.77&units=m&language=ja
のように HTTP GET を実行すると、
{
  :
  :
 "observation":{
  "class":"observation",
  "expire_time_gmt":1445420253,
  "obs_time":1445418000,
  "obs_time_local":"2015-10-21T18:00:00+0900",
  "wdir":40,
  "icon_code":33,
  "icon_extd":3300,
  "sunrise":"2015-10-21T05:51:54+0900",
  "sunset":"2015-10-21T16:58:54+0900",
  "day_ind":"N",
  "uv_index":0,
  "uv_warning":0,
  "wxman":"wx1500",
  "obs_qualifier_code":null,
  "ptend_code":1,
  "dow":"水曜",
  "wdir_cardinal":"北東",
  "uv_desc":"弱い",
  "phrase_12char":null,
  "phrase_22char":null,
  "phrase_32char":"快晴",
  "ptend_desc":"上昇",
  "sky_cover":"所により曇り",
  "clds":"SCT",
    :
    :
 }
}

といった感じの JSON テキストを得ることができ、指定した場所の天候状況が指定した言語で分かる、というものです(実際に試すともっと詳しい情報が得られています)。

ちなみにこの例で指定した位置(北緯 35.69 度、東経 139.77 度)は東京の神田駅あたりです。つまり日本国内の位置情報ですが、ちゃんと取得できていることがわかります。また language を en-US などにすると、数値情報は同じもので、日本語の部分が英語になったものを得ることができます。


同様にして、「予報」の API の場合は、1日ごとに昼と夜の天気予報を数日分まとめて取得できたり、24時間以内の情報を1時間おきにまとめて取得できる、というものでした。

なお、この API の詳細な使い方についてはリファレンスを参照ください:
https://twcservice.mybluemix.net/rest-api/#!/twc_observations_current/v2obscurrent


天気の情報は単に「雨が降るかどうか、わかると個人的に便利」なだけでなく、株式市況の出来高にも影響を与える可能性があり、その応用範囲はかなり広くなると思います。もちろん独自のアイデアを盛り込んだ天気アプリを作りたい人や、地図情報&位置情報を使ったアプリとの連携情報としても有用だと思っています。そういった情報が API で、位置や言語をピンポイントに指定して取得できる、というこの API は開発者という個人的な視点でも是非早く公式リリースされて欲しいと思っています(注 リリースされました)


API の(結果テキストの)仕様そのものはリリース前に変更される可能性があることをご了承ください。でも楽しみですよね。 リリースされたら、また改めて API の使い方を紹介する予定です。

※現時点では公開予定日や価格情報はまだ未定です

※2015/Oct/28 正式リリースにともなってタイトルと内容を一部変更しました。
 

ラズベリーパイを個人で2台持ってます。 うち一台(Raspberry Pi 2)は常用、というか常に自宅のネットワークに繋げて電源も入っています。SSH や VNC で常にアクセスできる環境が整っています。そういう意味でも「常用」です。

もう一台(Raspberry Pi B+)は、元々はこっちを常用機として使っていましたが、2を買ったらさすがに常用機としてはスペックの高い方にしたくなったため交換しました。結果として、こいつは電源を入れればいつでも動く状態ではありつつも余っていました。 そういうこともあり、新しいことにチャレンジする際の実験機的な位置付けになりました。ぶっちゃけ「壊れてもいいや」的な。


今回挑戦したのは「シリアル接続」です。ラズベリーパイ(以下「ラズパイ」)はネットワークに繋がった状態で起動していて、かつその IP アドレスが分かっていれば SSH や VNC でログインして使うことができて非常に便利なコンパクト Linux 環境です。でもネットワークに繋がっていても DHCP 環境などで IP アドレスが分からない場合にどうやって調べるかというと、(PiFinder など外部から IP アドレスを調べる専用のツールもあったりしますが)USB キーボードと HDMI ディスプレイを繋いで、キーボードからログインして ifconfig コマンドなどで IP アドレスを調べて・・・という手順が必要になります。が、そもそもキーボードを用意するとか、HDMI ケーブルを用意するとか、そのケーブルが届く範囲に外部ディスプレイを用意するとか、準備のハードルがかなり上がってしまいます。また(ネットワークの設定前の段階や、普段と異なるネットワーク環境に持ちだした場合などで)そもそもネットワークが繋がっていない状態では PiFinder も使えないので、結局設定のための最初の1回のためだけにこれらのキーボードやディスプレイの準備も必要になってしまいます。

それをどうにかするための方法の1つが「シリアル接続」です。要するにラズパイと手元の PC をシリアルに直結した上で、シリアル接続をサポートするターミナルアプリからラズパイに接続してログインする、という方法です。特に目新しい方法ではなく、PC に TCP/IP 環境がなかった昔はむしろこっちの方法が主流でした。オッサンの出番です(笑)!


用意するのはラズパイに加えてこの3つです:
(1) ラズパイで使える USB シリアルケーブル
(2) (1) のデバイスドライバ
(3) シリアル接続をサポートするターミナルアプリ


自分のメイン PC は Windows7 ということもあって、(1) にはこの変換ケーブルを使うことにしました:
https://strawberry-linux.com/catalog/items?code=15076

ラズパイの GPIO を使ってシリアル接続し、かつ USB ポートに変換して PC とつなげる、というケーブルです。Windows8 以降だとデバイスドライバが正しく動作しない、と書かれてます。Windows8 以降や他の環境をお使いのみなさん、ごめんなさい。

(2) のデバイスドライバですが、上記ケーブルの場合であればリンク先ページの「Windowsドライバ」と書かれたリンク先からダウンロードできます。


また (3) のターミナルアプリですが、自分は TeraTerm を使いました:
2015101601



では実際にシリアル接続するまでを紹介します。まずはデバイスドライバのインストールです。ラズパイの電源を切って、ケーブル接続も何もしない状態で、(2) のデバイスドライバをダウンロード&展開し、実行ファイルをダブルクリックしてインストールします:
2015101602


次に USB シリアルケーブルでラズパイと PC とを接続します。ラズパイ側の GPIO の 6(GND), 8(TXD), 10(RXD) 番のピンに、ケーブルの赤、緑、青のケーブルをそれぞれ差し込みます:
2015101603

そしてケーブルのもう一方の端を PC の USB ポートに接続します(ラズパイにはまだ電源の USB ケーブルはつなぎません)。するとプラグアンドプレイでデバイスドライバが導入されます。この画面だと COM6 として認識されたことになっていますが、ここは環境によって異なります:
2015101604


この段階でデバイスマネージャーを起動して COM のポートを確認すると、上記で "USB-to-Serial" のデバイスが、COM6 として認識されていることが分かります。つまりシリアル接続では(この例では)COM6 ポートを指定して接続すればよい、ということになります:
2015101605


では実際に接続してみます。シリアル接続をサポートするアプリ(この例では TeraTerm)を起動して、認識された COM ポートを指定してシリアル接続します:
2015101606


接続後に COM 接続の設定を変更します。TeraTerm の場合、デフォルトではシリアルポートのボーレートが低いので上げておきます。メニューの 設定→シリアルポート を選択します:
2015101607


指定 COM ポートのボーレートを 9600 から 115200 に変更して OK をクリックします:
2015101608


で、この状態に戻ります。これでラズパイにシリアル接続して待ち受け状態になりました:
2015101609


ここではじめてラズパイに電源ケーブルをつなぎます。するとブートプロセスの画面がシリアルターミナル画面に次々と表示され、ログインを待つ状態のプロンプトが表示されます:
2015101610

※途中で "Welcome to rescue login" というメッセージが表示されて画面が止まりますが、そこでは何もせずにしばらく待つと通常のブートプロセスが開始され、ログインプロンプトが表示されます。


ログインすると普通に操作できます。ちなみに ifconfig でネットワーク接続がないことを確認してみました:
2015101611


lo はループバックなので、本体から見た自分自身です。そして eth0 (有線LAN)と wlan0 (無線LAN)はハードウェアの認識こそされていますが、IP アドレスは割り振られていません(でも接続してこの画面が見れている、ということです)。

ネットワークがなくてもラズパイが使えることが確認できました!


前回までの続きです:
Bluemix のビルドパックを作る(1/3)
Bluemix のビルドパックを作る(2/3)


このシリーズは3回に分けて IBM Bluemix 用のビルドパックをゼロから作成する手順を説明するもので、今回はその3回目です:
(1) ビルドパックを作る上で知っておくべきこと
(2) ビルドパックを作るための準備作業    
(3) ビルドパックを作成して、実際に動作確認
  ←今回はここ

前回までに、ビルドパックを作成する上で知っておくべき仕組みや制限事項についてをまとめ、実際に PHP + Apache HTTP Server 環境のビルドパックを作る上で必要になるモジュール(ビルドパック実行時の権限では作れないモジュール)の作成を終えました。

では今回はこれらのモジュールを使って、実際のビルドパックを作成し、実際に IBM Bluemix 上のランタイムとして起動し、動作を確認するまでを紹介します。

ではビルドパック作成環境にログインします。前回の作業は Ubuntu 環境下で行う必要がありましたが、ここからは Ubuntu である必要はありません(Windows や Mac, Ubuntu 以外の Linux でも構いません)。が、以下はそのまま Ubuntu を使って作業する前提(つまり前回の作業で出来上がったモジュールもローカル内にあるという前提)で紹介をします。 というわけで改めて Ubuntu 環境に SSH 等でログインします:
2015100901


作業用のディレクトリを用意します。今回は /tmp/buildpack というディレクトリを新たに作成して、この中で作業することにします:
$ mkdir -p /tmp/buildpack
$ cd /tmp/buildpack


上記作業内容の (1) で紹介したように、ビルドパックは3つのスクリプトを用意することで作成します。この3つのスクリプトを /tmp/buildpack/bin 以下に作成します。3つのスクリプトは Ruby などのスクリプト言語を利用することもできますが、今回は(個人的な慣れもあって)シェルを使って記述することにします:
$ mkdir bin
$ cd bin
$ touch detect
$ touch compile
$ touch release
$ chmod 775 detect
$ chmod 775 compile
$ chmod 775 release
$ cd ..


また、このスクリプト(具体的には compile スクリプト)の中では、前回の作業 (2) で作成した PHP と Apache HTTP Server 2つのモジュールを使うことになります。これらのモジュールをあらかじめビルドパックのディレクトリ内にコピー(または移動)しておきます。前回の作業 (2) と異なる環境で今回の作業をしている場合は、前回の環境からこれらのモジュールを SFTP などで転送して取得してください:
$ mkdir -p download/httpd/2.4
$ mv /app/apache-2.4.16.tar.gz download/httpd/2.4
$ mkdir -p download/php/5.6
$ mv /app/php-5.6.14.tar.gz download/php/5.6


また、PHP および Apache HTTP Server の動作設定とも言える php.ini と httpd.conf ファイルもあらかじめ用意しておきます:
$ mkdir config
$ vi config/httpd.conf
   :

$ vi config/php.ini
   :


これらのファイルの内容は皆さんが作成していただいても構わないのですが、今回は日本語を使う前提で、比較的緩めの条件設定で環境構築をするような内容にしています。具体的な内容は以下のリンク先と同じものです。これらと同じ内容で2つのファイルを用意/編集しておくと、かなりゆるゆるで、本番環境としてはともかく、開発テスト用に便利な PHP ランタイムができます:
https://github.com/dotnsf/php-apache-buildpack/tree/master/config

なお、注意事項として Apache HTTP Server が動作するポートは固定値ではなく、必ず環境変数 PORT から取得して起動させる必要があることに注意してください。したがって httpd.conf 内の Listen ディレクティブの指定は必ず以下の様な指定になっている必要があります:
  :
  :
Listen ${PORT}
  :
  :


あらためて、ここから3つのスクリプトを作っていきます。まずは detect スクリプトを作ります。このスクリプトはビルドパックの適用に適した環境が整っているかどうかを判断して、ふさわしいと判断した場合だけ次にすすめるようにする、というためのスクリプトです。 今回は PHP + Apache HTTP Server のビルドパックなので、選択肢としては「無条件にふさわしいと判断する」というのもアリですが、勉強目的もあるので多少強引に何らかの条件を付けるようにしてみましょう。

というわけで、今回の detect スクリプトでは
 ドキュメントルートに index.php ファイルが存在していたらビルドパック適用条件を満たしている、
 index.php が存在していない場合はビルドパックを適用しない

という条件判断をさせることにします。

また、これも (1) の中で説明していますが、detect スクリプトは実行ディレクトリ("cf push" を実行した時のカレントディレクトリ)を引数に受け取ります。この引数を使って、detect スクリプトを以下のような内容で編集します:

※ bin/detect の中身
#!/usr/bin/env bash
################################################################################
# bin/detect <build-dir>                                                       #
################################################################################

# ---------------------------------------------------------------------------- #
# ドキュメントルートに index.php が存在している時だけ有効                      #
# ---------------------------------------------------------------------------- #
if [ -f $1/index.php ]; then
  echo "My PHP Env"
  exit 0
else
  exit 1
fi


これで detect スクリプトによって、カレントディレクトリに index.php ファイルが存在している時だけ実行結果として 0 を返して compile スクリプト続行、存在してない場合は 1 が返されて処理が止まる、という実装にしました。


続いて compile スクリプトを作ります。ここがいわば「ビルドパックの本体」といえる部分で、実際のサーバー環境を、このスクリプト1つだけで構築していくことになるものです。

この compile スクリプトの中では前回の作業 (2) で作成したモジュールを使います:

※ bin/compile の中身
#!/usr/bin/env bash
################################################################################
# bin/compile <build-dir> <cache-dir>                                          #
################################################################################

# ---------------------------------------------------------------------------- #
# 変数を設定                                                                   #
# ---------------------------------------------------------------------------- #
BIN_DIR=$(dirname $0)
BUILDPACK_DIR=`cd $(dirname $0); cd ..; pwd`
BUILD_DIR=$1
CACHE_DIR=$2

APACHE_VERSION="2.4.16"
APACHE_PATH="apache"
PHP_VERSION="5.6.14"
PHP_PATH="php"

# ---------------------------------------------------------------------------- #
# ドキュメントルート(/app/www/)の設定                                          #
# ---------------------------------------------------------------------------- #
cd $BUILD_DIR

mkdir -p $CACHE_DIR/www
mv * $CACHE_DIR/www
mv $CACHE_DIR/www .

# ---------------------------------------------------------------------------- #
# コンパイル済みの Apache HTTP Server を展開                                   #
# ---------------------------------------------------------------------------- #
APACHE_DIR="${BUILDPACK_DIR}/download/httpd/2.4/apache-$APACHE_VERSION.tar.gz"
echo "-----> Bundling Apache version $APACHE_VERSION"
tar -xvf $APACHE_DIR

# ---------------------------------------------------------------------------- #
# コンパイル済みの PHP を展開                                                  #
# ---------------------------------------------------------------------------- #
PHP_DIR="${BUILDPACK_DIR}/download/php/5.6/php-$PHP_VERSION.tar.gz"
echo "-----> Bundling PHP version $PHP_VERSION"
tar -xvf $PHP_DIR 

# ---------------------------------------------------------------------------- #
# httpd.conf と php.ini を上書き                                               #
# ---------------------------------------------------------------------------- #
ls -al $BUILDPACK_DIR
cp $BUILDPACK_DIR/config/httpd.conf $APACHE_PATH/conf
cp $BUILDPACK_DIR/config/php.ini $PHP_PATH

# ---------------------------------------------------------------------------- #
# php のパスを設定                                                             #
# ---------------------------------------------------------------------------- #
mkdir -p bin
ln -s /app/php/bin/php bin/php

# ---------------------------------------------------------------------------- #
# Apache HTTP Server 起動スクリプト(boot.sh)作成                               #
# ---------------------------------------------------------------------------- #
cat >> boot.sh <<EOF
for var in \`env|cut -f1 -d=\`; do
echo "PassEnv \$var" >> /app/apache/conf/httpd.conf; done touch /app/apache/logs/error_log touch /app/apache/logs/access_log tail -F /app/apache/logs/error_log & tail -F /app/apache/logs/access_log & export LD_LIBRARY_PATH=/app/php/ext export PHP_INI_SCAN_DIR=/app/www echo "Launching apache" exec /app/apache/bin/httpd -DNO_DETACH EOF chmod +x boot.sh # ---------------------------------------------------------------------------- # # キャッシュディレクトリをクリア # # ---------------------------------------------------------------------------- # rm -rf $CACHE_DIR

最後に release スクリプトを作ります:

※ bin/release の中身
#!/usr/bin/env bash
################################################################################
# bin/release <build-dir>                                                      #
################################################################################

# ---------------------------------------------------------------------------- #
# boot.sh を実行するような YAML ファイルを生成                                 #
# ---------------------------------------------------------------------------- #
cat << EOF
config_vars:
    MYENV: myphp
default_process_types:
    web: sh boot.sh
EOF

これでビルドパックは完成です。作業した /tmp/buildpack 以下のディレクトリ/ファイル構成は以下の様な状態になっているはずです:
/tmp/buildpack/
 |- bin/
 |   |- compile
 |   |- detect
 |   |- release
 |- config/
 |   |- httpd.conf
 |   |- php.ini
 |- download/
     |- httpd/
     |   |- 2.4/
     |   |    |- apache-2.4.16.tar.gz
     |- php/
         |- 5.6/
              |- php-5.6.14.tar.gz


ではこのビルドパックを実際に使ってみます。が、そのためにはこのビルドパックをインターネット上の Git リポジトリに公開する必要があります。普段お使いの環境にオリジナルの Git 環境があればそこを使ってもいいのですが、今回は GitHub 上に公開しましょう。GitHub のアカウントを取得できていない場合は取得して、ログインまでを済ませておきます:
2015101002


画面右上の "+" 印をクリックし、"New repository" を選択して、新しいソースリポジトリを作成します:
2015101003


リポジトリの名前、説明(オプション)、そして Public リポジトリか Private リポジトリかを選択します。名前は何でもいいのですが、わかりやすいように "php-apache-buildpack" としました。説明はオプションで加えます。GitHub の有料アカウントであれば Private リポジトリを選ぶこともできますが、せっかくなので(というか、この後の話がややこしくならないように)Public を選択して公開しちゃいましょう。最後に "Create Repository" ボタンをクリックします:
2015101004


するとこんな感じの画面になり、ソースリポジトリが新規に追加できました。この時の URL (https://github.com/(ユーザー名)/(リポジトリ名)) を後で使うのでメモしておいてください。今はまだ中身が空ですが、ここに先程作ったビルドパックを転送します:
2015101005


改めて作業環境に戻ります。ここからは git クライアントによる作業になるため、git が必要です。git コマンド未導入の場合はコマンドラインで以下のように入力して git をインストールしておきます:
$ sudo apt-get install git

そしてビルドパックを作成したディレクトリ(/tmp/buildpack)に移動して、以下のコマンドを入力し、上記で作成した GitHub 上のリポジトリに転送します:
$ cd /tmp/buildpack
$ git init
$ git add .
$ git commit -m 'first commit'
$ git remote add origin https://github.com/****(先程メモしたリポジトリのURL)****.git
$ git push -u origin master
(GitHub 上のユーザー名を入力)
(GitHub のパスワードを入力)

転送完了後、改めてリポジトリの URL にブラウザでアクセス(まだ開いていればリロード)すると、作成したビルドパックが転送され、中身が入ったリポジトリになっているはずです。これでビルドパックの公開もできました:
2015101006



では最後にこのビルドパックを使って、実際に Bluemix 上にランタイムを1つ構築してみます。cf ツールをインストールしたマシンのあるディレクトリに index.php という名前で、以下のような phpinfo(); を実行するだけの内容のファイルを作成します:
<?php phpinfo(); ?>

また Bluemix 上にランタイムを1つ作ります。言語は(この後に変えるので)何を指定しても構いません。この例では dotnsf-php-20151010 という名前で作成していますが、実際には一意になるような名前を指定してください:
2015101001


そしてこの index.php ファイルが存在しているディレクトリから cf ツールで Bluemix 上にログインし、作成したビルドパックを指定してこのランタイムにプッシュします:
> cf login -a https://api.ng.bluemix.net/
(Bluemix のユーザー名を指定)
(パスワードを指定)

> cf push dotnsf-php-20151010 -b https://github.com/dotnsf/php-apache-buildpack.git
   :
   :
#0   running   2015-10-10 08:37:34 PM   0.2%   61.9M of 128M   163.5M of 1G


プッシュが成功したら、実際にこのランタイムの URL にアクセスして、phpinfo() の結果が表示されることを確認します。ちゃんと PHP のアプリケーションサーバーとして動いていることが確認できました:
2015101002


この中身をよく見ると、ビルドパックを作成した際に指定した内容で稼働していることが確認できます。というわけで元の(Bluemix の)PHP ランタイム環境ではなく、カスタマイズして作成した PHP ランタイムが動いていることも分かります:
2015101003


長い連載になりましたが、これで Bluemix のビルドパックを作って、公開して、実際に使ってみる所までが確認できました。PHP 以外のビルドパックを作る場合も、(権限の問題がないものであれば)この応用で作れると思います。是非色々チャレンジしていただけると嬉しいです。

このページのトップヘ