本スライドは，「10 common errors when pushing apps to cf」 http://www.slideshare.net/greensight/10-common-errors-when-pushing-apps-to-cloud-foundry/ を，作者の許可を得て，Noburou TANIGUCHI ( https://github.com/nota-ja ) が翻訳したものです。

2. 本スライドは
http://www.slideshare.net/greensight/10-common-
errors-when-pushing-apps-to-cloud-foundry/
を，作者の許可を得て，"
Noburou TANIGUCHI ( https://github.com/nota-ja )"
が翻訳したものです。

3. Cloud Foundry にアプリケーションを
push する際の典型的な10のエラー
Junjie Cai (Jack)
IBM Bluemix runtime architect

4. Agenda
¢ アプリの push 時に何が起きているか
¢ クライアントのエラー
¢ 基盤のエラー
¢ アプリのステージング・エラー
¢ アプリの起動エラー

5. アプリの push 時に何が起きているか
[2] アプリの作成
[3] アプリのメタデータの保存
[7] アプリのステージング
[5] アプリのファイルの保存
[6] アプリの起動
[9] ステージング出力のストリーミング
[12]dropletの保存
[13] ステージング終了の通知
[14] ステージング済アプリの起動
[15] アプリの状態の通知
[4] upload app files[4] アプリのアップロード

6. どんな間違いが起きうるか
I. クライアントのエラー
II. 基盤のエラー
III. アプリの
ステージング・
エラー
IV. アプリの
起動エラー
[2] アプリの作成
[3] アプリのメタデータの保存
[7] アプリのステージング
[5] アプリのファイルの保存
[6] アプリの起動
[9] ステージング出力のストリーミング
[12]dropletの保存
[13] ステージング終了の通知
[14] ステージング済アプリの起動
[15] アプリの状態の通知
[4] upload app files[4] アプリのアップロード

7. I. クライアントのエラー
¢ ERR 1s (開始前)
— 原因 1: developer 権限を持つ space 内に居ない
— 原因 2: 古すぎる cf CLI クライアント
— 原因 3: 間違ったディレクトリーからの push
— アプリのパッケージの指定忘れ
— 原因 4: 意図しない manifest.yml の使用
¢ ERR 2: 他で確保されている route の使⽤用
— 解決策:
— ユニークなホスト名を “-n absolutelyunique” で指定
— “--no-route” or “--random-route” を使う
¢ ERR 3: organization のメモリ上限の超過
¢ ERR 4: 多すぎるディスク要求 (デフォルト上限は1GB)

8. I. クライアントのエラー
¢ ERR 5: アプリのアップロード失敗
— 原因 1: ネットワーク接続の問題
— 解決策: ネットワーク接続の修復
$ cf push jacklarge
Updating app jacklarge in org myorg / space myspace as myself...
OK
Uploading jacklarge...
Uploading app files from: e:BackdMailstest
Uploading 1.1G, 1 files
Error uploading application.
Error performing request: Put https://xyz/v2/apps/51cb5e33-8.../bits?async=true: dial tcp: i/o timeout
FAILED
Sample error

9. I. クライアントのエラー
— 原因 2: アップロードのタイムアウト (デフォルトは15分) or サイズ
上限の超過 (デフォルトは1GB)
— 解決策
— 不要なファイルを “.cfignore” を使って除外
— 例： ローカルの node_modules を除外する
— 全ての依存ライブラリーをアップロードするのではなく，それらをステージ
ング時にカスタム buildpack を使ってインストールする
— ファイル数が多い時は, 繰り返し push を行い，個々の push で差分アップ
ロードが行われることを利用して，アップロード済ファイル数を増やす
$ cf push jacklarge
Updating app jacklarge in org myorg / space myspace as myself...
OK
Uploading jacklarge...
Uploading app files from: e:BackdMailstest
Uploading 1.1G, 1 files
Done uploading
FAILED
Error uploading application.
The app package is invalid: Package may not be larger than 1073741824 bytes
Sample error

10. II. 基盤のエラー
¢ ERR 6s:
— Unable to connect
— 500
— 4xx
¢ 原因: "
様々な基盤コンポーネントの問題
¢ Diagnosis
— CF_TRACE を true にして実際に
どのステップで問題が起きてい
るのかを明らかにする
— 基盤のログを解析する
Database の問題
Blob store の問題
DEA に空きがない
Loggregator の問題
DEA に空きがない
Router or CloudController の問題
Done uploading
FAILED
Error uploading application.
Server error, status code: 500, error code: 0, message:
Sample error

11. III. アプリのステージング・エラー"
- buildpack のエラー
¢ ERR 7s: 不不正な buildpack 名 or URL
— 原因 1: 間違った buildpack 名
— 解決策: “cf buildpacks” を実行し使用可能な buildpack を調べる; 管理者に不
足している buildpack を “cf create-buildpack” で追加するよう依頼する
— 原因 2: ネットワークの問題 or 間違った buildpack URL による
buildpack の clone の失敗
Server error, status code: 400, error code: 100001, message: The app is invalid:
buildpack notexist is not valid public url or a known buildpack name
Cloning into '/tmp/buildpacks/java-buildpack'...
fatal: could not read Username for 'https://github.com': No such
device or address
Cloning into '/tmp/buildpacks/java-buildpack'...
FAILED
Server error, status code: 400, error code: 170001, message:
Staging error: cannot get instances since staging failed
Cloning into '/tmp/buildpacks/nope-buildpack'...
FAILED
Server error, status code: 400, error code:
170001, message: Staging error: cannot get
instances since staging failed

12. III. アプリのステージング・エラー"
- buildpack のエラー
¢ ERR 8: detect の失敗
— 原因 1: 誤ったアプリのパッケージ
— zip 内にアプリのルート・フォルダーを作ってはいけない
— 原因 2: 間違ったディレクトリーからの push
— 原因 3: 必要な buildpack がインストールされていない
— 調査⽅方法: “cf buildpacks” を実⾏行行し提供されている buildpack を確認
— 解決策: ⾜足りないものを “cf create-buildpack” でインストールするよう管理理者に依頼
— 原因 4: buildpack の⽋欠陥: detect コード内でアプリのファイルを変更更!!!
Server error, status code: 400, error code: 170003, message: An app was not
successfully detected by any available buildpack

13. ¢ ERR 9: compile の失敗
— 解析
— (あれば) buildpack の trace 機能を使う
— Java/Liberty buildpack: cf set-env <appname> JBP_LOG_LEVEL DEBUG
— Node.js buildpack: cf set-env <appname> npm_config_xyz またはアプリの
パッケージのルートに .npmrc ファイルを置く
— loglevel = silly
— PHP buildpack: cf set-env <appname> BP_DEBUG true
— “cf logs <appname> --recent” を実行し，エラー後の直近のログを取る
— ステージング時に別のターミナルで “cf logs <appname>” を実行
Staging failed: Buildpack compilation step failed
FAILED
Server error, status code: 400, error code: 170004, message: App staging failed in the buildpack compile phase
III. アプリのステージング・エラー"
- buildpack のエラー

14. — 原因 1:アプリのパッケージもしくはファイルの問題
— 例: node.js アプリの package.json のフォーマットがまちがっている
— 原因 2: 外部の依存ライブラリー等にアクセスできない
— 例: NPM のリポジトリーにアクセスできない
— 解決策: 外部リポジトリー等への接続をチェック
— Security Group が該当リポジトリーに接続可能な設定になっているか
2015-04-27T12:06:35.20-0400 [STG/0] ERR parse error: Expected separator between values at line 12,
column 13
2015-04-27T12:06:35.20-0400 [STG/0] OUT Staging failed: Buildpack compilation step failed
2015-04-27T12:18:47.65-0400 [STG/0] OUT -----> Installing dependencies
2015-04-27T12:19:58.33-0400 [STG/0] OUT npm ERR! network getaddrinfo ENOTFOUND
2015-04-27T12:19:58.33-0400 [STG/0] OUT npm ERR! network This is most likely not a problem with
npm itself
2015-04-27T12:19:58.33-0400 [STG/0] OUT npm ERR! network and is related to network connectivity.
2015-04-27T12:19:58.33-0400 [STG/0] OUT npm ERR! network In most cases you are behind a proxy or
have bad network settings.
III. アプリのステージング・エラー
- compile エラー

15. III. アプリのステージング・エラー
- compile エラー
— 原因 3: ステージングのタイムアウト (デフォルト15分)"
→ 突然無言で終了
— 解決策: ステージングに時間がかからないようにする. 例えば巨大なランタイム・
バイナリはキャッシュする
— 注: CF_STAGING_TIMEOUT は CLI の待ち時間を変えるだけ
— 原因 4: ステージング時のメモリ消費過多 (デフォルト上限1GB)"
→ 突然無言で終了
— 解決策: buildpack がステージング時にまめにメモリを開放することを確認
— 原因 5: ステージング時のディスク消費過多 (デフォルト上限2GB)
— 解決策: buildpack がステージング時にまめに一時ファイルを削除することを確認
2015-04-27T16:49:36.22-0400 [STG/0] ERR /tmp/buildpacks/java-buildpack/bin/compile:41:in `write': Disk
quota exceeded - /tmp/staged/app/some_file (Errno: DQUOT)

16. III. アプリのステージング・エラー
- compile エラー
— 原因 6: 適合しないレベルの buildpack の使⽤用
— 解決策: 外部 buildpack の master ブランチを使う push を避ける"
リリースされたバージョンを使う⽅方が良良い, 例例えば
cf push <appname> -b https://github.com/cloudfoundry/java-buildpack.git#v3.0
— 原因 7: 間違った buildpack が選ばれている"
(detected_buildpack の値を確認)
— 解決策
— “-b” オプションで buildpack 明⽰示的に指定"
(“cf buildpacks” で表⽰示される) admin buildpack 名も使⽤用可能
— アプリが疑わしいサイン・ファイル（※）を含んでいないか?"
（※訳注: "detect" に反応するファイル）
— 原因 8: buildpack のスクリプトのパーミッション; 例例) “x” ビットが偽
— 解決策: “x” を buildpack 内の実⾏行行可能なスクリプト全てに設定

17. IV. アプリの起動エラー
¢ ERR 10: アプリ起動のタイムアウトまたは失敗
-----> Uploading droplet (14M)
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
FAILED
Start app timeout
(Or, “Start unsuccessful”)
$ cf app jackruby
Showing health and status for app jackruby in org myorg / space myspace as myself...
OK
requested state: started
instances: 0/1
usage: 128M x 1 instances
urls: jackruby.mybluemix.net
last uploaded: Wed Apr 29 18:40:40 UTC 2015
state since cpu memory disk
#0 crashing 2015-04-29 02:42:28 PM 0.0% 0 of 0 0 of 0

18. IV. アプリの起動エラー
— 解析
— “cf logs <appname> --recent” を実行し，エラー後の直近のログを取る
— ステージング時に別のターミナルで “cf logs <appname>” を実行
2015-04-29T12:35:49.43-0400 [STG/27] OUT -----> Uploading droplet (14M)
2015-04-29T12:35:54.37-0400 [DEA/27] OUT Starting app instance (index 0) with guid
ceb4f93b-6306-4842-8637-1d1731412bdc
2015-04-29T12:37:06.75-0400 [DEA/27] ERR Instance (index 0) failed to start accepting connections
2015-04-29T12:37:06.76-0400 [API/8] OUT App instance exited with guid
ceb4f93b-6306-4842-8637-1d1731412bdc payload: {"cc_partition"=>"default", "droplet"=>
"ceb4f93b-6306-4842-8637-1d1731412bdc", "version"=>"d237ca74-f30a-41fc-afd8-fe8f66152698",
"instance"=>"b7e9b891ddd7474f828412bd1d7bb329", "index"=>0, "reason"=
>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to accept connections within health check timeout",
"crash_timestamp"=>1430325426}
2015-04-29T12:37:07.00-0400 [App/0] ERR
…
2015-04-29T14:27:51.12-0400 [STG/8] OUT -----> Uploading droplet (14M)
2015-04-29T14:27:54.83-0400 [DEA/8] OUT Starting app instance (index 0) with guid
ceb4f93b-6306-4842-8637-1d1731412bdc
2015-04-29T14:28:06.98-0400 [API/3] OUT App instance exited with guid
ceb4f93b-6306-4842-8637-1d1731412bdc payload: {"cc_partition"=>"default", "droplet"=>
"ceb4f93b-6306-4842-8637-1d1731412bdc", "version"=>"73474c66-caaa-470b-ad88-28e854c7db83",
"instance"=>"0baf945674c94a9db294caa6ce0b991d", "index"=>0, "reason"=
>"CRASHED", "exit_status"=>0, "exit_description"=>"app instance exited", "crash_timestamp"=>1430332086}
2015-04-29T14:29:07.02-0400 [DEA/8] ERR Instance (index 0) failed to start accepting connections

19. IV. アプリの起動エラー
— 原因 1: 起動に時間がかかりすぎる
— 普遍的な解決策:
— “-t” オプションで起動タイムアウトを延ばす"
デフォルトは 60 秒, 最長 180 秒まで
— 180 秒では不十分?
— 根本原因 1: 起動時の初期化処理過多; 例) 大量データのロード
— 解決策 1: “--no-route” を使って起動後, 初期化が終了したら
“map-route” を実行
— 解決策 2: 遅延初期化 and/or 非同期初期化
— 根本原因 2: 間違った待ち受けポート設定
— 解決策: アプリが $PORT を使っていることを確認
— 根本原因 3: 外部ネットワーク接続のタイムアウト
— 解決策: 外部リポジトリー等への接続可否の確認"
Security Group が正しく設定されていることの確認

20. IV. アプリの起動エラー
— 原因 2: アプリのロジックのエラー
— サービス・バインディングを忘れている?
— 原因 3: メモリ消費過多
— 解決策:
— メモリ・リークのチェック
— メモリ割り当てを増やして再 push "
cf push <appname> -m 2G
— 原因 4: ディスク消費過多"
(割り当て上限に達すると, アプリはディスクにそれ以上書き込めなくなる)
— 解決策: ディスク割り当てを増やして再 push"
cf push <appname> -k 2G"
注: プロバイダーが設定した上限 (デフォルト値:2G) を超えることはできない

21. IV. アプリの起動エラー
— 上級解析テクニック
— アプリが crash してもコンテナーを生かし続ける (→ “cf files” 等が可能になる)
— IBM JDK であれば, JVM が終了する前に -Xdump:tool という JVM option を
使ってスクリプトを走らせることができる 例:"
cf se <appname> JVM_ARGS -Xdump:tool:events=vmstop,exec="sleep 1d"
右記と組み合わせるとなお良い: -Xdump:heap+java:events=vmstop
— アプリ全般向けの方法：起動コマンドを修正し “;sleep 1d” を追加"
cf push <appname> -c “<original_command> ;sleep 1d” --no-route
— コンテナーが落ちないよう，エージェントをメイン・プロセスとして起動し，"
アプリの解析を行う
— cf-ssh
— Bluemix の “Development mode”
— 最終 tip: “cf delete” で全ての履歴を削除し再 push

22. I. クライアントのエラー
II. 基盤のエラー
III. アプリの
ステージング・
エラー
IV. アプリの
起動エラー
[2] アプリの作成
[3] アプリのメタデータの保存
[7] アプリのステージング
[5] アプリのファイルの保存
[6] アプリの起動
[9] ステージング出力のストリーミング
[12]dropletの保存
[13] ステージング終了の通知
[14] ステージング済アプリの起動
[15] アプリの状態の通知
[4] upload app files[4] アプリのアップロード
まとめ

23. Thanks!