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

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

タグ:cloudfoundry

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

 

自宅のローカル環境に 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 はオープンソース PaaS である Cloud Foundry をベースに作られています。ということは Cloud  Foundry の API を Bluemix に対して使う、ということもできるわけです。

実際に試してみた様子を以下に記載します。なお、実行にあたっては Bluemix のアカウントと、実行環境として curl を利用します。以下の例では CentOS 6 上の curl を使っていますが、他のプラットフォームでもほぼ同様に使えるはずです。また以下の例では北米データセンターを対象に API を実行しますが、他のデータセンターを使う場合は、"ng" の部分を "eu-gb"(英国)か "au-syd"(オーストラリア)といった具合に書き換えて実行してください:


(1) アクセストークンの取得

具体的な API の利用の前に OAuth のアクセストークンを取得しておく必要があります(このアクセストークンを使って個別の API を実行します)。

以下の curl コマンドを実行します(青字部分がレスポンスです):
# curl -XPOST -H"Application/json" -u "cf:" --data "username=username@xxxx.com&password=P@ssw0rd&grant_type=password&scope=" https://login.ng.bluemix.net/UAALoginServerWAR/oauth/token

{
 "access_token":"(accessToken)", 
"token_type":"bearer",
"refresh_token":"*******", "expires_in":43199, "scope":"cloud_controller.read password.write cloud_controller.write openid", "jti":"********" }

"--data" に続く部分にログイン情報を含めています。username は Bluemix のログインIDです(上の例では username@xxxx.com を指定しています)。また password にパスワードを指定しています(上の例では P@ssw0rd を指定します)。それぞれ自分の情報に書き換えて実行してください。すると青字のような JSON テキストが返ってきます。この中の access_token の値(青太字の部分)がアクセストークンです。実際にはかなり長い文字列になっているはずですが、これを使って (2) 以降で API を実行します。


(2) API の実行

アクセストークンが取得できたら、その情報を使って Cloud Foundry API を実行します。Cloud Foundry API そのもののリファレンスはこちらを参照ください:
https://apidocs.cloudfoundry.org/231/

例えば「現在利用中のアプリケーションランタイムの一覧を取得」するには、この API を使います:
https://apidocs.cloudfoundry.org/231/apps/list_all_apps.html

具体的には以下の様な curl コマンドを実行します。ヘッダ情報(Authorization ヘッダ)に上記で取得したアクセストークンを指定しています:
# curl -H"Authorization: bearer (accessToken)" https://api.ng.bluemix.net/v2/apps

{
 "total_results": 15,
 "total_pages": 1,
   :
   :
 "resources":[
  {
   "metadata": {
    "guid": "(appGuid1)",
    "url": "/v2/apps/(appGuid1)",
    "created_at": "2015-03-09T02:49:49Z",
    "updated_at": "2016-02-20T06:23:39Z"
   },
    :
    :
  },
  {
   "meatadata": {
    "guid": "(appGuid2)",
     :
     :
  },
     :
     :
  }
] }

"resources" 内に配列形式でランタイムアプリケーションの情報が含まれているはずです。各ランタイムアプリケーションにはアプリケーション GUID と呼ばれる ID が割り振られており、その値は各ランタイムアプリケーション内の metadata.guid として確認できます。

では、今度はこのアプリケーション GUID を使って、このランタイムアプリケーションの環境変数情報を API で確認してみましょう。具体的にはこちらの API を利用します:
https://apidocs.cloudfoundry.org/231/apps/get_the_env_for_an_app.html
# curl -H"Authorization: bearer (accessToken)" https://api.ng.bluemix.net/v2/apps/(appGuid1)/env

{
 "staging_env_json": {
  "BLUEMIX_REGION": "ibm:yp:us-south"
 },
 "running_env_json": {
  "BLUEMIX_REGION": "ibm:yp:us-south"
 },
 "environment_json": {
 },
 "system_env_json": {
  "VCAP_SERVICES": {
   "relationship_extraction": [
    {
     "name": "Relationship Extraction-dc",
     "label": "relationship_extraction",
     "tags": [
      "ibm_beta",
      "watson",
      "ibm_created",
      "ibm_dedicated_public"
     ],
     "plan": "relationship_extraction_free_plan",
     "credentials": {
      "url": "https://gateway.watsonplatform.net/relationship-extraction-beta/api",
      "sids": [
       {
        "sid": "ie-es-news",
        "description": "information extraction from Spanish news"
       },
       {
        "sid": "ie-en-news",
        "description": "information extraction from English news"
       }
      ],
      "username": "(username)",
      "password": "(password)"
     }
    }
   ],
    :
    :
    :
   ]
  }
 },
 "application_env_json": {
   :
   :
 }
}

(appGuid1) に上記で確認したアプリケーション GUID を指定して実行します。すると上記のようなフォーマットで、このランタイムアプリケーションの環境変数情報が(VCAP_SERVICES もそれ以外も)まとめて取得できます。特に VCAP_SERVICES の credentials(上記の青太字部分)にはバインドしているサービスの接続情報が含まれており、その値を外部から API で確認できたことになります。


curl(HTTP) だけで Cloud Foundry API を Bluemix に対して使うことができる、ということが確認できました。これで複数のランタイムアプリケーションのステータスを確認する、といった管理用のアプリケーションも作れそうです。もちろん管理用途だけでなく、Bluemix のダッシュボードで実現しているようなアプリケーションを独自に作る、といったことも含めてできそうです。

 

IBM Bluemix から提供されている Node.js ランタイムを使ってみました。Bluemix 上で Node.js を使う場合特有のクセとかコツとかも含めて、その時の様子をまとめてみました:
2015100701


なお、今回は Bluemix 上へのデプロイを cf ツールで行います。cf ツールがインストール済みであることが前提になるので、導入できていない場合はお使いの環境にあった cf ツールをダウンロードして、インストールしておいてください:
https://github.com/cloudfoundry/cli/releases


まず、(Bluemix でない)一般的な Node.js 環境でハローワールド的なアプリを書くと、そのコードはこんな感じになると思います:
var http = require( 'http' );
var server = http.createServer(); // HTTPサーバー

// リクエストを受けたらメッセージを返すだけの処理
server.on( 'request', function( req, res ){
  res.write( 'ハロー Node.js ワールド!' );
  res.end();
});

server.listen( 80 ); // 80 番ポートで起動する場合

仮にこの内容を server.js というファイルで用意したのであれば、以下のコマンドで HTTP サーバーを起動して待ち受けることができます:
# node server.js


そして、このサーバーに対してブラウザで(普通に80番ポートに)アクセスすると、こんな感じで、期待通りのメッセージが表示されます:
2015100702


これと同じことを Bluemix で実現するにはどうすればいいでしょうか?まずは違いが分かるようにちょっとだけ server.js のメッセージを変えておきます:
var http = require( 'http' );
var server = http.createServer(); // HTTPサーバー

// リクエストを受けたらメッセージを返すだけの処理
server.on( 'request', function( req, res ){
  res.write( 'ハロー Node.js ワールド on Bluemix!' );
  res.end();
});

server.listen( 80 ); // 80 番ポートで起動する場合

次に Bluemix 上に Node.js のランタイムを作成しておきます。この例では dotnsf-js という名称で Node.js ランタイムを作っています。今回はサービスは不要です:
2015100703


そして普通の Bluemix 感覚で、この server.js だけが存在しているディレクトリを用意した状態で cf ツールからプッシュして、、、

いやいやいや、これでは動くはずがありません。プッシュした後に
# node server.js
のコマンドを実行する必要があるのに、その指定をしていません。


Bluemix では、これらランタイムの挙動に関する指定は package.json というファイルを作って指定する必要があります。今回は起動時に "node server.js" を実行する、というコマンドを指定したいので、以下のような内容の package.json ファイルを(server.js と同じフォルダに)作成します:
{
  "scripts": {
    "start": "node server.js"
  }
}

この server.js と package.json の2つのファイルが存在している状態で、そのフォルダから cf コマンドで Node.js ランタイムにプッシュしてみます:
> cf push dotnsf-js(ここは作成した Node.js ランタイムの名称)
Updating app dotnsf-js in org dotnsf@jp.ibm.com / space dev as dotnsf@jp.ibm.com...
OK

Uploading dotnsf-js...
   :
   :(結構時間がかかります)
   :
0 of 1 instances running, 1 failing
FAILED
Start unsuccessful

TIP: use 'cf logs dotnsf-js --recent' for more information

>

なんとプッシュが失敗してしまいました。何が原因なのでしょう?

メッセージにあるように "cf logs dotnsf-js --recent' コマンドで最新ログを見てみるとこんな感じのログが出力されていました:
> cf logs dotnsf-js --recent
   :
   :
   :
2015-10-07T11:49:36.80+0900 [App/0]      OUT > node server.js
2015-10-07T11:49:36.96+0900 [App/0]      ERR events.js:85
2015-10-07T11:49:36.96+0900 [App/0]      ERR       throw er; // Unhandled 'error' event
2015-10-07T11:49:36.96+0900 [App/0]      ERR             ^
2015-10-07T11:49:36.96+0900 [App/0]      ERR Error: listen EACCES
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at exports._errnoException (util.js:746:11)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at Server._listen2 (net.js:1139:19)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at listen (net.js:1182:10)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at Server.listen (net.js:1267:5)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at Object. (/home/vcap/app/server.js:13:8)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at Module._compile (module.js:460:26)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at Object.Module._extensions..js (module.js:478:10)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at Module.load (module.js:355:32)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at Function.Module._load (module.js:310:12)
2015-10-07T11:49:36.96+0900 [App/0]      ERR     at Function.Module.runMain (module.js:501:10)
   :
   :
   :

"node server.js" を実行した後に Server.listen が失敗しているっぽい。それってソースでいうと最後の
   :
   :
   :
server.listen( 80 ); // 80 番ポートで起動する場合

の部分ってこと? あれ、80 番ポートじゃないんだっけ?


実は Bluemix (CloudFoundry)上の Node.js は 80 番では起動しません。特定のあるポート番号で起動させて、それを 80 番ポートから転送しているのです(つまり直接 80 番ポートで起動させることが間違い)。

では何番のポートを指定して起動すればいいのでしょうか? この答は「環境変数から取得する必要がある」のでした。

というわけで、server.js を以下のように書き換えます:
var http = require( 'http' );
var server = http.createServer();

var cfenv = require( 'cfenv' );
var appEnv = cfenv.getAppEnv();

server.on( 'request', function( req, res ){
  res.write( 'ハロー Node.js ワールド on Bluemix!' );
  res.end();
});

server.listen( appEnv.port );

"cfenv" というモジュールを使って、CloudFoundry としてのランタイムの環境情報を取り出しています。そして listen の引数として指定するポート番号を、この環境情報のポート番号を参照して指定するように書き換えました。

また、cfenv モジュールを動的にロードするため、package.json ファイルにも変更を加えます。このアプリケーションの dependencies に cfenv を加えます:
{
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "cfenv": "1.0.x"
  }
}

cfenv は 1.0.* というバージョンを使いたいのですが、↑このように指定しておくと、1.0.x の最新版を探して加えてくれます:


これで準備が整いました。改めてこの2つのファイル(server.js と package.json)がカレントフォルダにある状態で cf ツールでプッシュすると成功して、Bluemix 上のランタイムにアクセスできるようになります:
2015100704



この「必要なモジュールを package.json の dependencies に指定してロードして使う」というのは、Node.js の便利なモジュール(Express とか ejs とか)を Bluemix 上で使う場合に必要になるので、覚えておくといいと思いました。


IBM Bluemix 環境に cf ツールでアプリケーションを push した後にログが表示されますが・・・
2015021601



このログを詳しく調べて、「コマンド実行後に何をやっているのか?」の説明をします。

なお、今回の説明内容の前提として、2015/02/16 時点の、Liberty Java アプリケーション(war ファイル)1インスタンスをデプロイしています。このアプリケーションでは MySQL をデータストアとしてバインドしています。その条件下でのログを紹介します:

まずログ全文はこんな感じです:
$ cf push dotnsf-20150212 -p GeoImgWeb.war
Updating app dotnsf-20150212 in org (ユーザー名) / space dev as (ユーザー名)...
OK

Uploading dotnsf-20150212...
Uploading app files from: GeoImgWeb.war
Uploading 2.4M, 258 files
Done uploading
OK

Stopping app dotnsf-20150212 in org (ユーザー名) / space dev as (ユーザー名)...
OK

Starting app dotnsf-20150212 in org (ユーザー名) / space dev as (ユーザー名)...
-----> Downloaded app buildpack cache (224K)
-----> Retrieving IBM 1.7.1_sr2fp1ifx-20141220 JRE (ibm-java-jre-7.1-2.1-pxa6470
_27sr2fp1ifx-20141220_02-sfj.tgz) ... (0.0s)
         Expanding JRE to .java ... (0.8s)
-----> Retrieving App Management Agent 2015.02.04_102631 (com.ibm.ws.cloudoe.app
-mgmt-proxy-agent.zip) ... (0.0s)
         Expanding App Management to .app-management (0.0s)
-----> Downloading and installing client jar(s) from https://download.run.pivota
l.io/mariadb-jdbc/mariadb-jdbc-1.1.8.jar (0.0s)
-----> Auto-configuration is creating config for service instance 'mysql-x3' of
type 'mysql'
-----> Liberty buildpack is done creating the droplet



-----> Uploading droplet (116M)

0 of 1 instances running, 1 starting
1 of 1 instances running

App started


OK

App dotnsf-20150212 was started using this command `.liberty/initial_startup.rb`


Showing health and status for app dotnsf-20150212 in org (ユーザー名) / spa
ce dev as (ユーザー名)...
OK

requested state: started
instances: 1/1
usage: 512M x 1 instances
urls: dotnsf-20150212.eu-gb.mybluemix.net
package uploaded: Mon Feb 16 01:15:44 +0000 2015

     state     since                    cpu    memory           disk
#0   running   2015-02-16 10:16:46 AM   2.8%   149.4M of 512M   182M of 1G

$ 

まず、push コマンド:
$ cf push dotnsf-20150212 -p GeoImgWeb.war

で「dotnsf-20150212 という Bluemix アプリケーションに、GeoImgWeb.war という Java アプリケーションをデプロイする」という命令をしています。この GeoImgWeb.war はカレントディレクトリに存在しているものとします。

その直後のログは以下のようになっています:
Updating app dotnsf-20150212 in org (ユーザー名) / space dev as (ユーザー名)...
OK

Uploading dotnsf-20150212...
Uploading app files from: GeoImgWeb.war
Uploading 2.4M, 258 files
Done uploading
OK

Stopping app dotnsf-20150212 in org (ユーザー名) / space dev as (ユーザー名)...
OK

デプロイ先のアプリケーションを更新するため、GeoImgWeb.war をアップロードして、そして dotnsf-20150212 を一旦停止しています。ここまではまあ一般的というか、Bluemix / Cloud Foundry 環境に特化した内容ではないのでわかりやすいと思います。

この後から少し特殊な処理になります:
Starting app dotnsf-20150212 in org (ユーザー名) / space dev as (ユーザー名)...
-----> Downloaded app buildpack cache (224K)
-----> Retrieving IBM 1.7.1_sr2fp1ifx-20141220 JRE (ibm-java-jre-7.1-2.1-pxa6470
_27sr2fp1ifx-20141220_02-sfj.tgz) ... (0.0s)
         Expanding JRE to .java ... (0.8s)
-----> Retrieving App Management Agent 2015.02.04_102631 (com.ibm.ws.cloudoe.app
-mgmt-proxy-agent.zip) ... (0.0s)
         Expanding App Management to .app-management (0.0s)
-----> Downloading and installing client jar(s) from https://download.run.pivota
l.io/mariadb-jdbc/mariadb-jdbc-1.1.8.jar (0.0s)
-----> Auto-configuration is creating config for service instance 'mysql-x3' of
type 'mysql'
-----> Liberty buildpack is done creating the droplet

dotnsf-20150212 を起動する処理の中身です。Java アプリケーションとしての基板となる Liberty Buildpack をダウンロードし、IBM Java 1.7.1 & App Management Agent & MariaDB JDBC 1.1.8 を続けてビルド(実際にはダウンロード)しています。これらはビルドパック内で定義されている処理です。これで droplet と呼ばれる実行可能なアプリケーションが作成されます。

その後、作成した droplet をアップロードしてアプリケーションインスタンスを起動します。ここでちょっと時間がかかります:
-----> Uploading droplet (116M)

0 of 1 instances running, 1 starting
1 of 1 instances running

App started

OK

実はここまでの段階でアプリケーションとしては利用可能になっています。最後にアプリケーションやサーバーリソースの状態を確認するためのコマンドが実行され、その結果が表示されています:
App dotnsf-20150212 was started using this command `.liberty/initial_startup.rb`


Showing health and status for app dotnsf-20150212 in org (ユーザー名) / spa
ce dev as (ユーザー名)...
OK

requested state: started
instances: 1/1
usage: 512M x 1 instances
urls: dotnsf-20150212.eu-gb.mybluemix.net
package uploaded: Mon Feb 16 01:15:44 +0000 2015

     state     since                    cpu    memory           disk
#0   running   2015-02-16 10:16:46 AM   2.8%   149.4M of 512M   182M of 1G

CPU やメモリ、ディスクリソースの状態と合わせてアプリケーションの状態が最後に表示されています。この例ではサーバーは1インスタンスなので1行だけで表示されていますが、複数インスタンスで起動している場合は複数行の結果になります。



 

このページのトップヘ