Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
本スライドは
http://www.slideshare.net/greensight/10-common-
errors-when-pushing-apps-to-cloud-foundry/
を,作者の許可を得て,"
Noburou TAN...
Cloud Foundry にアプリケーションを
push する際の典型的な10のエラー
Junjie Cai (Jack)
IBM Bluemix runtime architect
Agenda
¢ アプリの push 時に何が起きているか
¢ クライアントのエラー
¢ 基盤のエラー
¢ アプリのステージング・エラー
¢ アプリの起動エラー
アプリの push 時に何が起きているか
[2] アプリの作成	
[3] アプリのメタデータの保存
[7] アプリのステージング	
[5] アプリのファイルの保存	
[6] アプリの起動	
[9] ステージング出力のストリーミング	
[12]d...
どんな間違いが起きうるか
I. クライアントのエラー
II. 基盤のエラー
III. アプリの
  ステージング・
  エラー
IV. アプリの
  起動エラー
[2] アプリの作成	
[3] アプリのメタデータの保存
[7] アプリのステージ...
I. クライアントのエラー
¢  ERR 1s (開始前)
—  原因 1: developer 権限を持つ space 内に居ない
—  原因 2: 古すぎる cf CLI クライアント
—  原因 3: 間違ったディレクトリーからの...
I. クライアントのエラー
¢ ERR 5: アプリのアップロード失敗
—  原因 1: ネットワーク接続の問題
—  解決策: ネットワーク接続の修復
$ cf push jacklarge
Updating app jacklarge...
I. クライアントのエラー
—  原因 2: アップロードのタイムアウト (デフォルトは15分) or サイズ
上限の超過 (デフォルトは1GB)
—  解決策
—  不要なファイルを “.cfignore” を使って除外
—  例: ロ...
II. 基盤のエラー
¢  ERR 6s:
—  Unable to connect
—  500
—  4xx
¢  原因: "
様々な基盤コンポーネントの問題
¢  Diagnosis
—  CF_TRACE を true に...
III. アプリのステージング・エラー"
- buildpack のエラー
¢ ERR 7s: 不不正な buildpack 名 or URL
—  原因 1: 間違った buildpack 名
—  解決策: “cf buildpack...
III. アプリのステージング・エラー"
- buildpack のエラー
¢ ERR 8: detect の失敗
—  原因 1: 誤ったアプリのパッケージ
—  zip 内にアプリのルート・フォルダーを作ってはいけない
—  原因 ...
¢ ERR 9: compile の失敗
—  解析
—  (あれば) buildpack の trace 機能を使う
—  Java/Liberty buildpack: cf set-env <appname> JBP_LOG_LE...
—  原因 1:アプリのパッケージもしくはファイルの問題
—  例: node.js アプリの package.json のフォーマットがまちがっている
—  原因 2: 外部の依存ライブラリー等にアクセスできない
—  例: NPM ...
III. アプリのステージング・エラー

- compile エラー
—  原因 3: ステージングのタイムアウト (デフォルト15分)"
→ 突然無言で終了
—  解決策: ステージングに時間がかからないようにする. 例えば巨大なランタイ...
III. アプリのステージング・エラー

- compile エラー
—  原因 6: 適合しないレベルの buildpack の使⽤用
—  解決策: 外部 buildpack の master ブランチを使う push を避ける"
リリ...
IV. アプリの起動エラー
¢ ERR 10: アプリ起動のタイムアウトまたは失敗
-----> Uploading droplet (14M)
0 of 1 instances running, 1 starting
0 of 1 inst...
IV. アプリの起動エラー
—  解析
—  “cf logs <appname> --recent” を実行し,エラー後の直近のログを取る
—  ステージング時に別のターミナルで “cf logs <appname>” を実行
2015...
IV. アプリの起動エラー
—  原因 1: 起動に時間がかかりすぎる
—  普遍的な解決策:
—  “-t” オプションで起動タイムアウトを延ばす"
デフォルトは 60 秒, 最長 180 秒まで
—  180 秒では不十分?
— ...
IV. アプリの起動エラー
—  原因 2: アプリのロジックのエラー
—  サービス・バインディングを忘れている?
—  原因 3: メモリ消費過多
—  解決策: 
—  メモリ・リークのチェック
—  メモリ割り当てを増やして...
IV. アプリの起動エラー
—  上級解析テクニック
—  アプリが crash してもコンテナーを生かし続ける (→ “cf files” 等が可能になる)
—  IBM JDK であれば, JVM が終了する前に -Xdump:tool...
I. クライアントのエラー
II. 基盤のエラー
III. アプリの
  ステージング・
  エラー
IV. アプリの
  起動エラー
[2] アプリの作成	
[3] アプリのメタデータの保存
[7] アプリのステージング	
[5] アプリのフ...
Thanks!
Cloud Foundry にアプリケーションを push する際の典型的な10のエラー
Upcoming SlideShare
Loading in …5
×

Cloud Foundry にアプリケーションを push する際の典型的な10のエラー

4,666 views

Published on

本スライドは,「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 ) が翻訳したものです。

Published in: Software
  • Be the first to comment

Cloud Foundry にアプリケーションを push する際の典型的な10のエラー

  1. 1. 本スライドは http://www.slideshare.net/greensight/10-common- errors-when-pushing-apps-to-cloud-foundry/ を,作者の許可を得て," Noburou TANIGUCHI ( https://github.com/nota-ja )" が翻訳したものです。
  2. 2. Cloud Foundry にアプリケーションを push する際の典型的な10のエラー Junjie Cai (Jack) IBM Bluemix runtime architect
  3. 3. Agenda ¢ アプリの push 時に何が起きているか ¢ クライアントのエラー ¢ 基盤のエラー ¢ アプリのステージング・エラー ¢ アプリの起動エラー
  4. 4. アプリの push 時に何が起きているか [2] アプリの作成 [3] アプリのメタデータの保存 [7] アプリのステージング [5] アプリのファイルの保存 [6] アプリの起動 [9] ステージング出力のストリーミング [12]dropletの保存 [13] ステージング終了の通知 [14] ステージング済アプリの起動 [15] アプリの状態の通知 [4] upload app files[4] アプリのアップロード
  5. 5. どんな間違いが起きうるか I. クライアントのエラー II. 基盤のエラー III. アプリの   ステージング・   エラー IV. アプリの   起動エラー [2] アプリの作成 [3] アプリのメタデータの保存 [7] アプリのステージング [5] アプリのファイルの保存 [6] アプリの起動 [9] ステージング出力のストリーミング [12]dropletの保存 [13] ステージング終了の通知 [14] ステージング済アプリの起動 [15] アプリの状態の通知 [4] upload app files[4] アプリのアップロード
  6. 6. 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)
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. ¢ 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 のエラー
  13. 13. —  原因 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 エラー
  14. 14. 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)
  15. 15. 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 内の実⾏行行可能なスクリプト全てに設定
  16. 16. 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
  17. 17. 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
  18. 18. IV. アプリの起動エラー —  原因 1: 起動に時間がかかりすぎる —  普遍的な解決策: —  “-t” オプションで起動タイムアウトを延ばす" デフォルトは 60 秒, 最長 180 秒まで —  180 秒では不十分? —  根本原因 1: 起動時の初期化処理過多; 例) 大量データのロード —  解決策 1: “--no-route” を使って起動後, 初期化が終了したら “map-route” を実行 —  解決策 2: 遅延初期化 and/or 非同期初期化 —  根本原因 2: 間違った待ち受けポート設定 —  解決策: アプリが $PORT を使っていることを確認 —  根本原因 3: 外部ネットワーク接続のタイムアウト —  解決策: 外部リポジトリー等への接続可否の確認" Security Group が正しく設定されていることの確認
  19. 19. IV. アプリの起動エラー —  原因 2: アプリのロジックのエラー —  サービス・バインディングを忘れている? —  原因 3: メモリ消費過多 —  解決策: —  メモリ・リークのチェック —  メモリ割り当てを増やして再 push " cf push <appname> -m 2G —  原因 4: ディスク消費過多" (割り当て上限に達すると, アプリはディスクにそれ以上書き込めなくなる) —  解決策: ディスク割り当てを増やして再 push" cf push <appname> -k 2G" 注: プロバイダーが設定した上限 (デフォルト値:2G) を超えることはできない
  20. 20. 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
  21. 21. I. クライアントのエラー II. 基盤のエラー III. アプリの   ステージング・   エラー IV. アプリの   起動エラー [2] アプリの作成 [3] アプリのメタデータの保存 [7] アプリのステージング [5] アプリのファイルの保存 [6] アプリの起動 [9] ステージング出力のストリーミング [12]dropletの保存 [13] ステージング終了の通知 [14] ステージング済アプリの起動 [15] アプリの状態の通知 [4] upload app files[4] アプリのアップロード まとめ
  22. 22. Thanks!

×