「Cloud Foundry 百日行」第25日目は，ブラウザー上で動作するターミナル Butterfly です。
タイトルからわかるように，今回，百日行シリーズ初の「失敗」を述べる記事になります。Cloud Foundry も万能ではなく，当然動作に適さないアプリも中にはあるのですが，それを明らかにすることもまた有益であると考え，今回記事として公開する次第です。
基本情報
-
公式サイト(?)
http://paradoxxxzero.github.io/2014/02/28/butterfly.html -
その他参考情報
手順の概要は以下の通りです。
- 1) ソースコードの取得
- 2) コードの修正
- 3) Cloud Foundry 環境へのプッシュ
- 4) 動作確認
- 5) (おまけ) Cloud Foundry 環境の管理者権限を使っての動作確認
1. ソースコードの取得
$ git clone https://github.com/paradoxxxzero/butterfly.git
$ cd butterfly/
いつも通りです。
2. コードの修正
requirements.txt の修正
プッシュする前に，requirements.txt に不足しているライブラリーがあるので，それを追加します。
$ emacs requiments.txt
..
$ git diff
diff --git a/requirements.txt b/requirements.txt
index e20c23a..9117c11 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1 +1,2 @@
tornado>=3.2
+tornado_systemd
3. Cloud Foundry 環境へのプッシュ
このアプリは Python ベースなのですが，bosh-lite 環境にプッシュすると NodeJS アプリと判定され，NodeJS buildpack でステージングが行われてしまいます。
これは，NodeJS buildpack の detect (buildpack を適用するかどうかを判定するスクリプト) が「アプリのトップ・ティレクトリーに package.json というファイルがあるか」を判定基準にしていて，
if [ -f $1/package.json ]; then
かつ，実際にこのアプリのトップ・ディレクトリーに package.json があり，
さらに，NodeJS buildpack の適用順位が Python buildpack よりも前にあるために起きる現象です。
$ cf buildpacks
Getting buildpacks...
buildpack position enabled locked filename
java_buildpack 1 true false java-buildpack-v3.0.zip
ruby_buildpack 2 true false ruby_buildpack-cached-v1.4.2.zip
nodejs_buildpack 3 true false nodejs_buildpack-cached-v1.3.1.zip
go_buildpack 4 true false go_buildpack-cached-v1.3.1.zip
python_buildpack 5 true false python_buildpack-cached-v1.3.2.zip
php_buildpack 6 true false php_buildpack-cached-v3.2.1.zip
staticfile_buildpack 7 true false staticfile_buildpack-cached-v1.0.0.zip
binary_buildpack 8 true false binary_buildpack-cached-v1.0.0.zip
そこで，プッシュ時に陽に Python buildpack を使うよう指定します。
さらに今回は，アプリの起動コマンドも指定して，アプリをプッシュします。
$ cf push butterfly -b python_buildpack -c 'python butterfly.server.py --port=$PORT --host=$VCAP_APP_HOST --unsecure'
..
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: butterfly.10.244.0.34.xip.io
package uploaded: Tue Jul 7 11:46:07 UTC 2015
stack: cflinuxfs2
state since cpu memory disk details
#0 running 2015-07-07 08:46:46 PM 0.0% 58.8M of 256M 0 of 1G
アプリが起動しました。
4. 動作確認
ブラウザーからアプリにアクセスします。
最初の画面はこんな感じです：
GitHub の README に貼ってあるのとよく似た画面が表示されています。
「起動した！」と思ったのですが，ここで問題発生。
Cloud Foundry のアプリは，Warden というコンテナー内で起動するのですが，その際のユーザーは vcap になっています。そこで login: プロンプトに vcap と打ち込んで enter を押したところでハタと気づきました。
「パスワードがわからない」
そうなのです。パスワードがわからないと，ログインできませんし，当然何のコマンドも実行できません。
ということで，今回のアプリ Butterfly は，起動まではできたのですが，残念ながら「使えない」という結果になりました。
なお，時期は未定ですが，Cloud Foundry の次のメジャー・リリースである v3 では， アプリのインスタンスにSSHでアクセスできる機能が追加される予定 です。この機能があれば，Butterfly が「使える」ようになるかもしれません。
5. (おまけ) Cloud Foundry 環境の管理者権限を使っての動作確認
ここからは完全におまけですが，Cloud Foundry 環境の管理者権限を使って，コンテナー内の vcap ユーザーにパスワードを設定し，そのパスワードでログインして本当にアプリが動作しているかを試してみます。
百日行シリーズの「ユーザーの視点から Cloud Foundry の使い方を示す」という趣旨からは外れますが，個人の興味の範囲で試してみました。
各コマンドの詳細な説明は省略しますので，質問等あれば，別途ご連絡ください。
- Warden コンテナーが動作している DEA にログインします
$ bosh ssh runner_z1/0
- スーパーユーザーになって，
bosh_4xqfadsn8@dab3959e-f426-4ef6-8602-34be08a31058:~$ sudo -s
- アプリのインスタンスが動作しているコンテナーを特定し，
root@dab3959e-f426-4ef6-8602-34be08a31058:~# find /var/vcap/data/warden/depot/ -name butterfly.server.py
/var/vcap/data/warden/depot/18q8si997t6/tmp/rootfs/home/vcap/app/butterfly.server.py
root@dab3959e-f426-4ef6-8602-34be08a31058:~# ps -ef | grep 18q8si997t6
root 7312 1 0 11:46 ? 00:00:00 wshd: 18q8si997t6
root 7349 148 0 11:46 ? 00:00:00 /var/vcap/data/packages/warden/88b0ad837f313990ce408e50cd904f7025983213.1-95fe39abd3b1f23126ab20be93fc7de85b7bec0e/warden/src/oom/oom /tmp/warden/cgroup/memory/instance-18q8si997t6
root 7523 148 0 11:46 ? 00:00:00 /var/vcap/data/warden/depot/18q8si997t6/bin/iomux-spawn /var/vcap/data/warden/depot/18q8si997t6/jobs/47 /var/vcap/data/warden/depot/18q8si997t6/bin/wsh --socket /var/vcap/data/warden/depot/18q8si997t6/run/wshd.sock --user vcap /bin/bash
root 7524 7523 0 11:46 ? 00:00:00 /var/vcap/data/warden/depot/18q8si997t6/bin/wsh --socket /var/vcap/data/warden/depot/18q8si997t6/run/wshd.sock --user vcap /bin/bash
root 7529 148 0 11:46 ? 00:00:00 /var/vcap/data/warden/depot/18q8si997t6/bin/iomux-link -w /var/vcap/data/warden/depot/18q8si997t6/jobs/47/cursors /var/vcap/data/warden/depot/18q8si997t6/jobs/47
root 11131 10869 0 12:19 pts/0 00:00:00 grep --color=auto 18q8si997t6
- コンテナーに入ります
root@dab3959e-f426-4ef6-8602-34be08a31058:~# /var/vcap/data/warden/depot/18q8si997t6/bin/wsh --socket /var/vcap/data/warden/depot/18q8si997t6/run/wshd.sock /bin/bash
- コンテナー内で
vcapユーザーのパスワードを変更します
root@18q8si997t6:~# passwd vcap
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@18q8si997t6:~# exit
-
ここで，先ほどの画面から
vcapユーザーでログインします
パスワードは先ほど設定したものを使います
ログインできました！ -
いろいろやってみました
ということで，irregular な方法ですが，動くことは確認できました。
なお次回は，この結果を受けて，別のターミナル・アプリについて，Takehiko Amano さんが書いてくださる予定です。
今回使用したソフトウェア
- cf-release (v211)
https://github.com/cloudfoundry/cf-release/tree/v211
( https://github.com/cloudfoundry/cf-release/tree/2121dc6405e0f036efa4dba963f7f49b07e76ffa ) - bosh-lite
https://github.com/cloudfoundry/bosh-lite/tree/0ccf6f54b1d11087b8356509832db80ec821eada - CF CLI (v6.11.2-2a26d55-2015-04-27T21:11:49+00:00)
https://github.com/cloudfoundry/cli/releases/tag/v6.11.2 - Butterfly
https://github.com/paradoxxxzero/butterfly/tree/ed03f94c8447fc186bfd9eb44f6c678e059fa35a
