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

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

タグ:cf

前2回の続きです:
IBM Bluemix にカスタムサービスを追加する(1/3)
IBM Bluemix にカスタムサービスを追加する(2/3)


前回作成した REST API を実際に IBM Bluemix のカスタムサービスとして登録し、利用するまで(正確には使用を終えてカスタムサービスから削除するところまで)の手順を紹介します。なおこの手順はコマンドラインツールである cf が必要になるので、インストールしていない場合は各自の環境にあった cf をあらかじめダウンロード&インストールしておいてください:
https://github.com/cloudfoundry/cli/releases


また、今回カスタムサービスとして登録する REST API は前回紹介した app.js が https://dotnsf-operation.mybluemix.net/ にデプロイされて動いているものとします。以下の説明でのこのホスト名部分を実際にみなさんがデプロイしたホスト名に合わせて読み替えてください:
2017021401

2017021401


まず最初に、以下で登録するカスタムサービスをバインドして動作確認するためのランタイムを用意しておきます。動作確認用のアプリケーション(後述)を PHP で用意したので、IBM Bluemix 上に PHP のランタイムを1つ作成します(以下の例では teyande-php-env という名前で作成しています)、なおこの段階ではサービスは何もバインドしないでください:
2017021402


このランタイムに以下の内容の PHP アプリケーションをプッシュします:
https://github.com/dotnsf/phpEnv


上記アプリケーション(index.php)はシンプルに「ランタイムサーバー上の全環境変数とその値を表示する」というアプリケーションです。プッシュ後にサーバーにアクセスすると以下のような画面になります。この時点ではサービスを1つもバインドしていないので、環境変数 VCAP_SERVICES の値は空オブジェクトを示す "{}" となっていることが確認できるはずです:
2017021403


ここまでで準備は完了です。では前回紹介したサービスを IBM Bluemix のカスタムサービスとして登録した上でインスタンス化し、このランタイムにバインドした上で、この環境変数がどのように変わるかを確認してみます。

コマンドプロンプトかターミナルを起動し、上記の PHP ランタイムと同じデータセンター(この場合は US-SOUTH)の自分の組織に cf コマンドでログインします:
2017021404


カスタムサービスを利用するにためには Cloud Foundry の「サービスブローカー」(カスタムカタログのように理解してください)に登録しておく必要があります。まず現在のサービスブローカー一覧を確認するため "cf service-brokers" コマンドを実行して、この時点では何も登録されていないことを確認します:
2017021301
 ↑"No service brokers found"(何も登録されていません)です


ではサービスブローカーを新規に1つ作成します。以下のパラメータを付けてコマンドを実行します:
> cf create-service-broker サービスブローカー名 認証ユーザー名 認証パスワード サービスの基本URL --space-scoped
2017021302


今回、サービスブローカー名は "dotnsf-operation" とします。認証のユーザー名とパスワードは dotnsf-operation の Catalog API などが実行される時用に指定した auth_user / auth_pass の値を指定します(詳しくは前回の記事参照)。サービスの基本 URL は今回 "https://dotnsf-operation.mybluemix.net" です。そして最後にオプションの "--space-scoped"(同一組織内のユーザーが使えるサービスとするための指定)を加えています。

コマンドが成功したことを確認し、再度 "cf service-brokers" を実行してみます。先程は結果に何も含まれていませんでしたが、今度は直前に作成したばかりの "dotnsf-operation" サービスブローカーが、指定した URL で登録されていることを確認してください:
2017021303


これで dotnsf-operation API がカスタムカタログに登録された状態になりました。ただ IBM Bluemix のウェブ UI ではカスタムカタログを表示する画面が存在していないので、この時点ではまだウェブ UI には現れませんが、cf からは同様にインスタンスを作成することができるようになっています。

というわけで、続けて cf でこのサービスをインスタンス化してみます:
> cf create-service サービスブローカー名 プラン名 サービス名

サービスブローカー名は dotnsf-operation の Catalog API(GET /v2/catalog) 内で定義したもの(今回の場合は dotnsf-operation-service)を指定します。プランも同様に Catalog API 内で定義したもの(今回は "free" と "enterprise" の2つ)の中から指定できますが、今回は "free" を指定しています。最後に IBM Bluemix 内でのサービス名として "dotnsf-operation-1" と指定しています:
2017021304


ここまでの手続きが完了すると、dotnsf-operation サービスがインスタンス化され、ウェブ UI の利用中サービス一覧の中にも表示されるようになります:
2017021301


この時点でサービスを選択し、管理タブを開くと Dashboard API で定義した内容が表示されるはずです(https で Dashboard API にアクセスできることが条件です):
2017021000


ではこのサービスを最初に作成した PHP ランタイムにバインドしてみましょう。PHP ランタイムの画面に移動し、接続タブの「既存に接続」をクリックします:
2017021302


現在利用中のサービスインスタンスの一覧が表示されます。その中に "dotnsf-operation-1" という名前のサービスが含まれているはずなので、これを選択して「接続」をクリックします。そしてこの内容をランタイムの環境変数にも反映させるため「再ステージング」します:
2017021303


改めて同ランタイムの接続タブを参照すると、"dotnsf-operation-1" サービスが追加されていることを確認できます。ここで「資格情報の表示」をクリックします:
2017021304


今回の dotnsf-service の Bind API では credentials 情報として uri だけを追加していました。そのためこのサービスインスタンスの資格情報にも uri 1つだけが credentials 情報として表示されていることが確認できるはずです:
2017021305


改めてランタイムのトップ画面にアクセス(リロード)します。今回は先程と異なり dotnsf-operation-1 サービスがバインドされているので、環境変数 VCAP_SERVICES は空オブジェクトではなく、dotnsf-operation-1 の情報が表示されているはずです。credentials 情報も先程確認したものと同じものが表示されています:
2017021306



・・・というわけで、IBM Bluemix のカスタムサービスを作成して、登録して、インスタンス化して、ランタイムとバインドして環境変数に反映させる、という一連の作業ができることを確認できました!

最後に使い終わったサービスブローカーを削除する手順を紹介しておきます。まず(同サービスブローカーを使っているランタイムからのバインドを全て解除した上で)サービス一覧画面からインスタンス化されたサービスを削除します:
2017021305


サービスが削除されるとウェブ UI からは見えなくなります。が、まだサービスブローカーには登録されているので、以下の cf コマンドでサービスブローカーからも削除します:
> cf delete-service-broker サービスブローカー名
2017021306


このコマンドが成功すると、サービスブローカー一覧からも削除されます。念のため "cf service-brokers" コマンドで確認します:
2017021307




久しぶりの超大作ブログとなり、3回に分けて紹介しましたが、IBM Bluemix のカスタムサービスを作るために実装しないといけない内容や、実装後の登録方法などを紹介できたつもりです。自分が作った REST API を IBM Bluemix に統合して使いたい場合や、公式なサードパーティ API としての登録を検討する場合に必要となる実装がどんなものかを説明しました。

今回紹介した内容はあくまで「同一組織内でのみ有効なカスタムサービス」の登録方法および手順の紹介でしたが、全 IBM Bluemix ユーザー向けに実装する場合であっても同様の API 実装は必要になります。そういったエコシステムを活性化する上での役立つ情報になれば幸いです。


(参考)
 https://www.ibm.com/blogs/bluemix/2017/01/extend-bluemix-service-broker/

IBM LinuxONE(メインフレーム版 Linux)挑戦シリーズ。今回は IBM Bluemix でも使う cf コマンドラインツールの導入に挑戦します:
2017012000


cf ツールは IBM のクラウド環境である IBM Bluemix や、同製品がベースとしているオープンソース PaaS 環境である CloudFoundry をコマンドラインから操作するためのツールです。手元で作成したソースコードやアプリケーションファイル一式を Bluemix/CloudFoundry のランタイムにデプロイする時などに使うコマンドラインアプリケーションで、これがあれば Bluemix や CloudFoundry の管理操作が可能になるものです。主なプラットフォーム(Windows, Linux, MacOS)向けのツールはこちらから最新版の実行バイナリがダウンロードできるようになっています:
https://github.com/cloudfoundry/cli/releases

2017012001


ここでバイナリが提供されている Linux は x86(_64) アーキテクチャの Linux です。他の Linux に関しては公式からは提供されていませんが、パッケージマネージャーから簡単に導入できるようになっているものもあったりします(例:ラズベリーパイの RaspbianOS)。

残念ながら s390x(IBM LinuxONE)プラットフォーム向けのバイナリは提供されていない模様です。ただ cf ツール自体もオープンソース製品なので、ソースを入手して自分でビルドできる可能性もあります。というわけで挑戦してみた様子を以下に紹介します。 前提として IBM LinuxONE は IBM LinuxONE コミュニティクラウド上に RHEL 6.x で用意しているものとします(1インスタンスが最大 120 日間無料で利用できます):
IBM LinuxONE コミュニティクラウドを使う(2017年1月版)


またオープンソースツールである cf コマンドは、Go 言語で記述されています。というわけでビルドには Go 言語の環境が必要になります。IBM LinuxONE で Go 言語を使えるようにするための手順は以下を参照ください(最後の環境変数 GOPATH と PATH の設定までを行う必要があります):
IBM LinuxONE コミュニティクラウド上で Go 言語を動かす


早速ソースコードを入手してビルドを、、、の前に1つ準備が必要です。ドキュメントにかかれている手順を IBM LinuxONE 環境でそのまま実行しても途中でエラーになってしまいました。試行錯誤の結果、これを回避するために事前にパスの通ったディレクトリに "s390x-linux-gnu-gcc" という名前で gcc が使えるようにしておく必要がありそうでした。というわけで(この例では /usr/local/bin/ 以下に)シンボリックシンクを作っておきます:
# ln -s /usr/bin/gcc /usr/local/bin/s390x-linux-gnu-gcc

改めて、まずはソースコードを入手しましょう。go コマンドを使って以下のコマンドを実行します:
# go get code.cloudfoundry.org/cli

コマンドが成功すると、$GOPATH/src/code.cloudfoundry.org/cli 以下に cf ツールのソースコードが展開されます。このディレクトリに移動して bin/build コマンドを実行してビルドします:
# cd $GOPATH/src/code.cloudfoundry.org/cli
# bin/build

ビルドが成功すると、cf コマンドが $GOPATH/src/code.cloudfoundry.org/cli/out/ 以下に作成されます。このコマンドにパスを通すか、パスの通ったディレクトリ(以下の例では /usr/local/bin)以下にシンボリックリンクを張って実行できるようにすれば準備完了です:
# ln -s /usr/local/go/src/code.cloudfoundry.org/cli/out/cf /usr/local/bin/cf

これで cf ツールがコマンドラインから実行できるようになりました(青字は出力結果):
# cf -v
cf version 6.23.1+d752ec1.2017-01-19


LinuxONE については、自分も最初は「メインフレーム上の Linux で、普段使っているプログラミング言語やツール、サーバー類がどこまで使えるんだろう?」と半信半疑だったのですが、いざ使ってみると x86_64 アーキテクチャと比べてもほとんど変わらずに使えるということが分かってきました。事実 cf ツールが動くと分かった今、IBM Bluemix の、オープンソース系のアプリケーション開発やテストをこれ単体で行えるだけの環境はほぼ揃っているように感じます。


なお、今回紹介した手順は(基本的には)以下のドキュメントを参考にしています:
https://github.com/cloudfoundry/cli/blob/master/.github/CONTRIBUTING.md

 

IBM Bluemix のアプリケーションベースの1つが Cloud Foundry です。オープンソース版の PaaS 環境でもある Cloud Foundry を拡張したものが IBM Bluemix ですが、この Cloud Foundry が利用するコンテナ技術に新しいテクノロジーが加わりました。それが Diego です:
https://docs.cloudfoundry.org/concepts/diego/diego-architecture.html

2016120700


これまでの Cloud Foundry では DEA(Droplet Execution Agent) というコンテナ技術を使っていました。この進化版としての、新しいコンテナフォーマットや SSH ログインをサポートした新しいコンテナ、それが Diego です。DEA と Diego の技術的な相違点など、詳細はこちらをご覧ください:
https://docs.cloudfoundry.org/concepts/diego/dea-vs-diego.html


さて、この Diego は先日 IBM Bluemix でも有効になりました。現状は DEA と Diego が両方サポートされている状態で、デフォルトは DEA になっています。またこれまでに Bluemix 上で作成して動いていた CloudFoundry ランタイム(以下、 "CF ランタイム")アプリケーションは DEA コンテナのまま実行されています。なので、以下に紹介するような特別なことをしなければ特に何も変わらずに動いている/動く、ということになります。


一方、Diego コンテナでは DEA ではできなかったいくつかの新しい機能が有効になっています。その1つが ssh によるリモートログインです。というわけで、Bluemix アプリケーションを Diego コンテナに切り替えて、ssh ログインができることを確認する手順を以下に紹介します。


まず、現状で Diego コンテナを利用するには cf コマンドラインツールを利用する必要があります。また Diego コンテナを使う場合、cf ツールのバージョンは 6.13.0 以上である必要があります。なお cf ツールのバージョンを確認するには "cf -v" と実行してください:
$ cf -v
cf version 6.22.2+a95e24c-2016-10-27

cf コマンドを使ったことがなかったり、古い cf コマンドを使っている Bluemix ユーザーは、まずは自分の環境にあった cf ツールを GitHub からダウンロードしてインストールしておいてください:
https://github.com/cloudfoundry/cli/releases


次に Diego 機能を使うために cf コマンドに Diego-Enabler プラグインをインストールします。これは以下のコマンドでインストールできます:
$ cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org/
$ cf install-plugin Diego-Enabler -r CF-Community

これで Diego-Enabler が使える cf コマンドが用意できました。では実際に Bluemix 上の CF ランタイムアプリケーションを Diego コンテナに移行してみましょう。

今回、サンプルとして "dotnsf-diego-java" という名前の CF アプリケーションを Liberty for Java ビルドパックで作成しました。以下、この名前を使ってコマンドを実行する様子を紹介しますので、みなさんのアプリケーションの名前に置き換えてお読みください。なお、この時点では(これまで通り)DEA コンテナ上で動いているアプリケーションです:
2016120701


ためしにブラウザからアクセスすると、デフォルトの "Hello World!" が表示されます:
2016120702


このランタイムを Diego コンテナ上に移行してみましょう。まずは cf ツールでログインを行います:
$ cf login -a https://api.ng.bluemix.net/ -u (ユーザーID)
API エンドポイント: https://api.ng.bluemix.net/

Password> (パスワードを入力)
※↑の例では USA データセンターにログインしています。他のデータセンターの場合は "ng" の部分をデータセンターに合わせて変更してください。

最初に対象のランタイムアプリケーションを停止させる必要があります:
$ cf stop dotnsf-diego-java

停止が確認できたら、このランタイムのコンテナを Diego に変更します:
$ cf enable-diego dotnsf-diego-java

そして再スタートです:
$ cf start dotnsf-diego-java
  :
  :
要求された状態: started
インスタンス: 1/1
使用: 512M x 1 インスタンス
URL: dotnsf-diego-java.mybluemix.net
最終アップロード日時: Wed Dec 7 01:51:43 UTC 2016
スタック: cflinuxfs2
ビルドパック: Liberty for Java(TM) (WAR, liberty-16.0.1_3, buildpack-v3.5-20161114-1152, ibmjdk-1.8.0_20161019, env)

     状態   開始日時                 CPU      メモリー            ディスク           詳細
#0   実行   2016-12-07 11:05:40 AM   181.1%   512M の中の 97.9M   1G の中の 189.8M

この時点でアプリケーションは Diego コンテナ上で動いています。ただアプリケーションそのものには何の変更も加えていないので、見た目は変わっていません:
2016120702


ではこの Diego コンテナに SSH でログインして、アプリケーションを直接書き換えてみましょう。SSH でログインするには以下のコマンドを実行します:
$ cf ssh dotnsf-diego-java
vcap@18ce933a-65ca-4e3f-5f0c-d9fac300d6f9:~$  ←プロンプトが変わった!

ここは既に CF アプリケーションの中です。もちろん使えるコマンドには制約がありますが、例えば top コマンドを使ってサーバーリソースの利用状態を確認することもできます:
2016120703


ではアプリケーションを書き換えてみましょう。Liberty for Java ビルドパックの場合、アプリケーションは app/wlp/usr/servers/defaultServer/apps/myapp.war/ ディレクトリにあるのでここで移動し、vi で index.html を直接編集します:
$ cd app/wlp/usr/servers/defaultServer/apps/myapp.war
$ vi index.html

変更内容はどうでもいいのですが、とりあえず <body> タグの直後に目立つように <h1> タグのメッセージを追加してみました(↓赤枠部分を追加して保存):
2016120704


この状態で(再プッシュとかなしで)同アプリケーションをブラウザでリロードすると、入力したメッセージが画面に表示されて、アプリケーションが書き換わったことが確認できました:
2016120705


CF ランタイムは今までこれができないという制約があったのですが、Diego コンテナに切り替えることで課題を1つ克服できることになりますね。

自宅のローカル環境に Cloud Foundry v2 を導入してみました(注 自宅 Bluemix Local ではありません)

Cloud Foundry はオープンソースの PaaS(Platform as a Services) の名称です。IBM Bluemix を始め、多くの商用/非商用クラウドサービスの基盤として利用されている実績があります。元々は VMWare 社によって開発を行っていましたが、現在は 2014年12月に設立されたコミュニティ Cloud Foundry Foundation によって開発・管理・リリースが行われています(IBM も参画しています):
2016050203



【前提条件】

Intel x86_64 版の Ubuntu 14.04 環境が前提として必要です。同環境上に Cloud Foundry v2 Nise Installer を使って Cloud Foundry 環境を構築します。

なお、自分は以下の様なスペックの物理マシンを1台用意して、そこに Ubuntu 14.04 を導入しました:
メモリ: 12GB
HDD: 1TB
導入OS: Ubuntu Desktop 14.04 (要ネット接続)


ちなみに自分が使ったのは ASUS P30AD の(旧モデルの)現品処分特価品でした:
https://www.asus.com/jp/Tower-PCs/P30AD/

2016050201



メモリだけ 12GB に増設して、〆て50000円といった所です。この約 50000 円の ASUS 機が自宅 Cloud Foundry 環境になっています。今後同様の環境を作る人にとって、1つの目安となれば。


【Cloud Foundry 導入手順】


導入作業自体はシンプルです。まず Cloud Foundry v2 Nise Installer を動かすには Rbenv が必要です。そのため最初に Rbenv と、その前提となるパッケージをインストールします:
$ sudo apt-get install build-essential bison libreadline6-dev curl git-core zlib1g-dev libssl-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev autoconf libncurses5-dev

そして Cloud Foundry v2 Nise Installer を使って Cloud Foundry v2 を導入します:
$ sudo bash < <(curl -s -k -B https://raw.githubusercontent.com/yudai/cf_nise_installer/${INSTALLER_BRANCH:-master}/scripts/bootstrap.sh)

なお、この(2番目の)コマンドを実行してから完了するまでに、自分の環境で1時間ちょっとかかりました。コーヒーでも飲みながら完了を待ちましょう。

成功すると、最後に以下のようなメッセージが表示されてプロンプトに戻ります。「Ubuntu 10.04 の場合は再起動しろ」というメッセージが表示されていますが、自分は 14.04 でしたが念のため再起動しました:
  :
  :
Done!
You can launch Cloud Foundry with './scripts/start.sh'
Restart your server before starting processes if you are using Ubuntu 10.04

これで Cloud Foundry のローカル環境構築自体は完了です。Cloud Foundry は上記の導入手順を実行したユーザーのホームディレクトリの ~/cf_nise_installer/ フォルダ以下に導入されているはずです。

なお、この後で cf コマンドを使ったオペレーションを行うため、cf コマンドも同環境上にダウンロードして導入しておきます。cf コマンドのウェブページから Debian 64 bit の最新版インストーラをダウンロードします:
2016050201



自分が 2016/May/02 にこの作業を行ったタイミングでは、cf ツールの最新版のバージョンは 6.17.0 で、ダウンロードファイル名は cf-cli-installer_6.17.0_x86-64.deb でした。異なるバージョンおよびファイル名だった場合は適宜読み替えて以下を実行してください。

ダウンロードした cf コマンドラインツールを dkpg を使ってインストールします:
$ sudo dpkg -i cf-cli-installer_6.17.0_x86-64.deb

【Cloud Foundry 起動】

ではローカル環境に導入した Cloud Foundry を起動します。起動は以下のコマンドを実行します:
$ sudo ~/cf_nise_installer/scripts/start.sh

少しずつ Cloud Foundry のモジュールが起動していく様子がわかります。最後に以下のようなメッセージが表示されてコマンドプロンプトが戻ったら、全ての Cloud Foundry モジュールの起動が完了したことを意味します(自分の環境だと Cloud Foundry 起動完了まで10分くらいかかりました):
  :
  :
+ tail -n +3
+ grep -v -E '(running|accessible)$'
+ sudo /var/vcap/bosh/bin/monit summary
+ break
+ grep -v -E '(running|accessible)$'
+ tail -n +3
+ sudo /var/vcap/bosh/bin/monit summary
+ set +x
All processes have been started!
Login : 'cf login -a https://api.192.168.0.10.xip.io -u admin -p c1oudc0w --skip-ssl-validation'
Download CF CLI from https://github.com/cloudfoundry/cli

最後のメッセージを見ると分かるのですが、API サーバー名が api.192.168.0.10.xip.io となっています。この NISE Installer を使うと、このような名前(xxxxx.IPアドレス.xip.io)で動作する DNS サーバーが自動的にローカルマシンに導入されて動きます。自分の環境では Cloud Foundry 導入マシンの IP アドレスが 192.168.0.10 だったので、このようなサーバー名になっていますが、皆さんの環境ではこの部分は皆さんの Cloud Foundry 導入マシンの IP アドレスになっているはずです。以下を適宜置き換えて参照ください。


【cf ツールで動作確認】

では cf ツールを使って動作確認してみます。まずは api サーバーを指定して Cloud Foundry にログインします。なお API サーバーに指定する名前は api.(このサーバーのIPアドレス<この例では 192.168.0.10>).xip.io と指定します。またログイン時に指定するメールアドレスとパスワードですが、デフォルトではそれぞれ admin / c1oudc0w となっています:
$ cf login -a api.192.168.0.10.xip.io -u admin -p c1oudc0w --skip-ssl-validation

最初の段階ではデフォルトの組織は DevBox となっていますが、スペースが未定義です。そこでスペース dev を作成して、組織 DevBox と紐付けます(最初の1回だけ、この作業が必要です):
$ cf create-space dev
$ cf target -o DevBox -s dev

では適当なアプリケーションをローカルの Cloud Foundry 上にデプロイしてみましょう。今回は PHP アプリケーションをデプロイしてみます:
$ mkdir phpinfo
$ cd phpinfo
$ echo "<?php phpinfo(); ?>" > index.php $ cf push phptest -b https://github.com/cloudfoundry/php-buildpack

↑のコマンドライン操作では、中身が <?php phpinfo(); ?> だけの index.php ファイル1つだけからなる phpinfo フォルダを作り、このフォルダを丸ごと phptest という名前のアプリケーションとしてプッシュ(デプロイ)しています。またプッシュの際に GitHub 上の PHP ビルドパックを指定して、これを使ってプッシュしています。

このプッシュ操作が成功すると、以下のように実行中のステータスが表示されます:
2016050202


いまプッシュした phptest アプリケーションを "cf apps" コマンドで確認すると、同アプリケーションは phptest.192.168.0.10.xip.io というサーバー名で動いていることがわかります(青字部分が出力メッセージ):
$ cf apps
admin として組織 DevBox / スペース dev 内のアプリを取得しています...
OK

名前      要求された状態   インスタンス   メモリー   ディスク   URL
phptest   started          1/1            1G         1G         phptest.192.168.0.10.xip.io

早速同マシンのデスクトップ環境のウェブブラウザから http://phptest.192.168.0.10.xip.io/ にアクセスしてみました:
2016050204


動いたーっ!! これで我が自宅にも Cloud Foundry 環境を構築することができました!


【今後の課題?】
一応動いたこの環境ですが、必ずしもあまり安定していない気がしています。使っているうちに同じ URL にアクセスしても、"502 Bad Gateway" エラーになってしまうこともあります:
2016050205


この場合は以下のコマンドでアプリを再ステージングすると復活するのですが・・・原因とかまだよく分かっていません:
$ cf restage phptest


まあ Cloud Foundry 環境としてはマシンがちと貧弱すぎる感は否めないのですが、どーなんでしょ。


ともあれ、とりあえず github のビルドパックを指定して、PHP ランタイムが動く、ということは確認できました。カスタマイズとかほとんどしてないけど、インストーラーを実行するだけなので楽ちんでした。今後はサービスとかも組み合わせてアプリを作ってみよう。


IBM Bluemix のウェブダッシュボードにログインせずに、コマンドラインだけでランタイム&サービスを作り、サービスをランタイムにバインドした上でアプリケーションをプッシュする方法を紹介します。 

ウェブのダッシュボードだと上記のような順序になるのですが、これをコマンドラインで行おうとすると、少し手順が異なります。具体的には以下の様な作業順序で進めていくことになります:
(1) (必要であれば)cf コマンドのインストール
(2) (必要であれば)cf コマンドの確認
(3) ログイン
(4) ランタイムの作成&アプリケーションのプッシュ
(5) (必要であれば)サービス一覧の確認
(6) サービス作成
(7) サービスのランタイムへのバインド
(8) ランタイムの再ステージ
(9) (必要であれば)アプリケーションの再プッシュ



ではこれらの流れに沿って具体的に紹介します。 特に今回は PHP ランタイムに ClearDB(MySQL) データベースサービスをバインドしたアプリケーション環境に PHP ファイルをプッシュしてアプリケーションを作る、という例を紹介しますが、他のランタイムや他のサービスを使う場合もほぼ同様にして構築することができるので、その場合は適宜読み替えて実行してください:


(1) cf コマンドのインストール

もしもまだ cf コマンドラインツールを導入していない場合は、github.com から自分の環境にあった最新版のインストーラーをダウンロードして導入してください:
https://github.com/cloudfoundry/cli/releases

2016011401


導入後、コマンドラインプロンプト(Mac や Linux であればターミナル)を起動しておきます。



(2) cf コマンドの確認

この作業は必須ではないのですが、cf コマンドで利用できるコマンドの一覧を確認することができます。cf コマンドラインツールのバージョンによっては新機能が追加される可能性もあるので、cf コマンドを導入したり、最新版にバージョンアップしたりした場合は一度実行しておくといいでしょう。

以下のコマンドを実行して cf コマンドヘルプを確認しておきます:
> cf -h

おそらく一画面内には収まりきらないような情報が出力されると思います。後から何度か確認する可能性もあるので、出力結果をテキストファイルに保存しておいて、後から参照できるようにしておくとよいでしょう:
> cf -h > cf_help.txt (コマンドヘルプの結果を cf_help.txt に保存しておく場合の例)

以下の内容は全てこのコマンド一覧で紹介されている機能の説明になります。どんなものがあるのか、一度目を通しておくことをおすすめします。



(3) ログイン

まず cf コマンドラインツールを使って Bluemix の API サーバーにログインします。が、その前に、もしも以下の作業をプロクシ環境内から行う場合はコマンドライン環境でプロクシの設定をしておく必要があります。 プロクシの設定は以下のコマンドを実行します:
> set HTTPS_PROXY=http://xx.xx.xx.xx:8080/

cf コマンドラインツールで実行するコマンドは HTTPS を使って API サーバーとのやりとりを行うので、HTTPS のプロクシサーバーを指定しておく必要があります。上記のようなコマンドで HTTPS 用のプロクシサーバーとポート番号を指定しておいてください。


あらためて、cf コマンドライン環境で Bluemix の API サーバーにログインします:
> cf login -a https://api.ng.bluemix.net/

上記コマンドの "ng" の部分は、利用するデータセンターに併せて変更する必要があります。自分が使うデータセンターに併せて、上記の ng 部分を適宜変更して指定してください:
データセンター"ng" 部分の値
米国ng
英国eu-gb
オーストラリアau-syd


するとユーザー ID(E-mail) とパスワードを聞かれます。Bluemix のウェブダッシュボードにログインする際に指定する ID とパスワードを指定してログインしてください。

※なお、ユーザーID とパスワードはそれぞれ -u / -p オプションでコマンド実行時に指定することも可能です(以下に実例も紹介しています)。詳しくは以下のコマンドでオプション内容を確認してください:
> cf login -h


(4) ランタイムの作成&アプリケーションのプッシュ

さてここからが紹介する内容の肝になる部分です。まずは cf コマンドでランタイムを作成します。

ウェブのダッシュボード画面から行う場合はランタイムの種類と、アプリケーション名を指定してランタイムを生成しますが、実際には同時に(ハローワールド的な)サンプルアプリがプッシュされます。 このサンプルアプリに相当するものを事前に用意しておく必要もあります。

今回は PHP のビルドパックを使ったランタイム環境を作ることにします。なので、事前に以下の内容で index.php ファイルをカレントディレクトリに作成しておきます:
<?php phpinfo(); ?>

この内容は PHP の環境情報を HTML 出力するだけの PHP ファイルです。動作確認目的でよく使われるファイルですが、今回はこのファイルをプッシュすることにします。

ではアプリケーション名(以下の例では "myapp-php-20160114" 実際には一意な名称)を指定して cf コマンドで PHP ランタイムを作成します:
> cf push myapp-php-20160114

カレントディレクトリに上記で作った index.php ファイルが存在していれば自動的に PHP ビルドパックが選ばれて、PHP ランタイムが作られます(-b オプションでビルドパックの URL を指定して、ビルドパックを強制することも可能です)。確認必須ではありませんが、コマンド実行後の時点で Bluemix ダッシュボードはこのような状態になっているはずです。(デフォルトの)1GB のメモリを搭載した PHP ランタイム1インスタンスが起動しています:
2016011402


また、この時点でカレントディレクトリにあった index.php ファイルがプッシュされているので、ランタイムの URL にアクセスすると、このような PHP 環境情報が出力されるはずです:
2016011403



(5) サービス一覧の確認

次はこの PHP ランタイムに MySQL データベースサービスをバインド(追加)してみます。具体的には ClearDB というサードパーティ製の MySQL DBaaS を使ってみます:
2016011404


サービスを cf コマンドで追加するには、追加したいサービスのサービス名称とプラン名称(とインスタンス名称)を指定する必要があります。現在 Bluemix から提供されているサービスのサービス名称およびプラン名称を確認するには以下のコマンドを実行します:
> cf marketplace

このコマンドは完了するまでに少し時間がかかります。またこのコマンドの結果も一画面に収まりきらないほどの量があるので、以下のコマンドでテキストファイルに出力して、後から参照できるようにしておくとよいでしょう:
> cf marketplace > marketplace.txt (サービス一覧の結果を marketplace.txt に保存しておく場合の例)

この出力結果を見ると、以下の様な一行が確認できます:
    :
    :
cleardb          spark          Highly available MySQL for your Apps. 
    :
    :

スペースで区切られて1つ目(cleardb)がサービス名称、2つ目(spark)がプラン名称、3つ目はその説明です(1つのサービスにプランが複数ある場合はカンマで句切られています)。このような行がずらっと出力されることを確認します。



(6) サービス作成

今回は ClearDB のSpark プラン(無料で 5MB 使えるプラン)を使いたいので、cf コマンドを以下のように実行します:
> cf create-service cleardb spark cleardb_inst

最後のパラメータである cleardb_inst は作成するインスタンスの名称であり、任意の名称を指定することができます(この後に同サービスを指定したりする際にはこの名称を指定することになります)。

ここまでのコマンド実行後の時点で Bluemix ダッシュボードはこのような(未バインドの)サービスが追加されている状態になっているはずです:
2016011405



(7) サービスのランタイムへのバインド

直前のコマンドで作成した ClearDB サービスを PHP ランタイムにバインドします。ランタイムアプリの名称(myapp-php-20160114)と、サービスインスタンスの名称(cleardb_inst)を指定して、以下の様なコマンドを実行します:
> cf bind-service myapp-php-20160114 cleardb_inst

ここまでのコマンド実行後の時点で Bluemix ダッシュボードではランタイムとサービスのバインドが完了しているはずです:
2016011406


ランタイムに複数のサービスをバインドする場合は (5) ~ (7) の手順を必要なだけ繰り返します。



(8) ランタイムの再ステージ

ここまででランタイムに必要なサービスをバインドする所までは完了しています。最後にランタイムを再ステージングして、この変更を反映させます:
> cf restage myapp-php-20160114

ここまでの作業で当初の目的が達成できたことになります。Bluemix ダッシュボードではランタイムに紐付けられたサービスの環境変数も確認できるような状態になりました:
2016011407



(9) アプリケーションの再プッシュ

この (9) の作業は必須ではありませんが、サービスの環境変数を確認した上でアプリケーションを変更して再デプロイしたいような場合は、(8) の作業後に必要な変更を加えて、再度アプリケーションファイルをプッシュしてください:
> cf push myapp-php-20160114


以上の説明ではところどころでウェブのダッシュボード画面を確認しながら作業するような内容になっていますが、流れが分かってしまえば必須ではありません。 つまり cf コマンドだけでランタイムを作ったり、サービスを追加したり、ランタイムにバインドしたり、再ステージングしたり、・・・ といった作業が可能であることが理解できたと思います。



(おまけ)一連の内容をバッチコマンドで実行する

上記内容をシェルスクリプトやバッチファイルにしておくと、このバッチファイルを実行するだけでログインして、ランタイムを作って、サービスを作ってバインドして、再ステージングさせる、なんてことも可能になります。

例えばこのような内容のテキストファイルを作ります。Windows であれば拡張子を .bat で、UNIX 系であれば拡張子を .sh などで保存します:
cf login -a https://api.ng.bluemix.net/ -u (USERID) -p (PASSWORD)
cf push myapp-php-20160114
cf create-service cleardb spark cleardb_inst
cf bind-service myapp-php-20160114 cleardb_inst
cf restage myapp-php-20160114

このコマンドを実行すれば上から順にコマンドが実行され、最終的には上で紹介したような一連の処理がまとめて行われて最後にランタイムを再ステージングする、ということが実現できます(本来はランタイム名やサービスインスタンス名を変数にするべきですが・・)。作業内容が決まっているような処理であればこの方が楽かもしれませんね。



今回紹介した作業以外にもスケールさせたり、メモリ量を変更したり、各種状態を確認したり、・・といった作業はcf コマンドでできるよう提供されています。その意味でも cf コマンドのヘルプ((2) で紹介した結果)は一度目を通しておくことを改めてオススメします。

このページのトップヘ