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

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

タグ:cf

自分はラズパイ(Raspberry Pi 3B)をリモートの開発環境として使っています。自宅内ネットワークで常時起動させ、OpenVPN 経由で外からもアクセスできるようにしています。その辺りの設定についてはこちらを参照してください:
OpenVPN でローカル(自宅)ネットワークに VPN 接続する


そんなラズパイに各種開発環境やら docker やら TensorFlow やら、、を導入しています。これで外からも利用できる開発環境を構築しています:
http://dotnsf.blog.jp/tag/raspberrypi


さて、コーディングして動かすところまではこういったツールだけで問題ないのですが、1点だけ不便に感じる点がありました。それが「cf ツール」です。作ったアプリケーションを IBM Bluemix (Cloud Foundry) 環境上にデプロイする際に使うツールなのですが、公式にはラズパイ用のバイナリは提供されていません。なのでラズパイで開発して、動かして、テスト&デバッグして、、というところまではこの環境でできるのですが、作ったアプリを IBM Bluemix 上で動かす、という最後のステップの際に別の(cf ツールの導入された)環境に切り替えて行う、というちと面倒な手順をとる必要がありました:
Releases cloudfoundry/cli

2017080601


これをラズパイ環境のままで行えるようにする、というのが今回の目的です。実はこれまでにも IBM LinuxONE 環境などで同様の経験はしていて、その時は自分でソースからビルドして対応したりしていました:
IBM LinuxONE コミュニティクラウド上で cf コマンドを動かす

2017080602
(↑メインフレーム上で cf を動かしたのは、もしかすると世界中で自分だけかも・・)


で、同様の問題がラズパイで発生しているということです。というわけで、ラズパイ環境でも同様に cf ツールをビルドしてみました。以下はその手順紹介ですが、基本的には上記の LinuxONE 環境と同じことをしています。

まず cf ツールは go 言語で書かれているため、ビルドには go 言語が必要です。ラズパイ用の go 言語導入については以下を参照して、go 言語が動く環境を作っておいてください:
ラズパイに go 1.8 をインストールする

go 言語が動くようになったら次はソースコードの入手です。以下のコマンドを実行します:
$ go get code.cloudfoundry.org/cli

これで $GOPATH/src/code.cloudfoundry.org/cli 以下にソースコードが展開されます。これをビルドします:
$ cd $GOPATH/src/code.cloudfoundry.org/cli
$ bin/build

ビルドが成功すると $GOPATH/src/code.cloudfoundry.org/cli/out/ 以下に cf コマンドが生成されます。試しに動くかテストしてみます:
$ cd $GOPATH/src/code.cloudfoundry.org/cli/out
$ ./cf -v
cf version 6.29.0+35e54cd.2017-08-06

バージョン番号が表示され、ちゃんと動くことが確認できました。後はこのコマンドを PATH の通った所に移動すれば完成です。
$ sudo mv $GOPATH/src/code.cloudfoundry.org/cli/out/cf /usr/local/bin
$ sudo chown root.staff /usr/local/bin/cf


なお、このラズパイ版の cf コマンドについては困っていた方が他にもいたようで、たまに有志でビルドされたものが見つかります。僕が動作確認しているわけではないし、動作保証もできないのですが、こういった所から入手して使うという手段もありそうです:

https://github.com/mmb/cf-cli-pi
https://cf-cli-pi.s3.amazonaws.com/index.html


前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 ランタイムが動く、ということは確認できました。カスタマイズとかほとんどしてないけど、インストーラーを実行するだけなので楽ちんでした。今後はサービスとかも組み合わせてアプリを作ってみよう。


このページのトップヘ