IBM Bluemix を使ってアプリ開発を行い、「期待していた通りに動かない・・・ (--;」ということは普通にあると思っています。 そんな時のトラブルシューティングについて、大きく3つの原因パターンに分けて紹介します。
ケースその1 Bluemix 側に問題が発生している
何よりもまず最初に調べる必要なのがこれです。Bluemix 側に原因があってうまくいかないのか、自分のコードやアクションに問題があるのか、という切り分けです。
Bluemix のランタイムやサービスが正しく稼働していない場合(あるいはメンテナンス中の場合)、その機能を使ったアプリは当然うまく動かなくなります。そのため、まずは Bluemix の稼働ステータスを確認してください:
https://status.ng.bluemix.net/
↑このサイトでデータセンターリージョン毎/ランタイム・サービス毎の稼働状態を確認することができます(近い将来のメンテナンス情報もわかります):
おおまかにはこのサイトの情報で充分だと思いますが、認証機能などの内部的な機能レベルでの稼動状態を調べるにはこちらを参照ください:
http://estado.ng.bluemix.net/
IBM DevOps Services などの外部サービスを併用して使っている場合は、それらの併用サービスについても確認が必要になります。例えば IBM DevOps Services の稼動状態はこちらで確認できます:
http://status.hub.jazz.net/
これら上記4つの URL はブックマークしておくことをおすすめします。
ケースその2 プッシュ(デプロイ)できない
Bluemix 側に特に異常がないにもかかわらず、自分の作ったアプリケーションコードのプッシュ(デプロイ)に失敗する場合は、コードや設定ファイルの内容そのものに間違いが含まれている可能性を疑う必要があります。
例えば cf ツールを使って push したらこんな感じでエラーが発生することがあります:
エラーが出てプッシュが FAILED になってしまいました。さてどうしましょう?
このようなケースではプッシュ時のログを参照するのがいいです。その方法は上記の最後に書かれているように、cf logs コマンドに "--recent" オプションを付けて実行することで(直近のログを)確認できます:
この例だと composer の処理の中でエラーが発生しているようなメッセージが出力されていました。とすると、composer.json に間違いがあったのかな・・・と思って実際の composer.json ファイルを確認したらこんな内容でした:
閉じなければいけない大カッコが閉じられていませんでした。ケアレスミス! これが原因ですね。最後に "}" を追加してプッシュし直した所、エラーはなくなりました。これはあくまで一例ですが、プッシュ時のエラーに対してはプッシュ時のログを確認する、という対応が解決への近道になります。
ケースその3 プッシュしたアプリが正しく動かない
アプリケーションのプッシュ(デプロイ)には成功して、つまり Bluemix 上でアプリケーションが動いている状態になっていて、その上でアプリケーションが期待していたように動かない、ということがあります。コーディング内容と状態にもよりますが、画面にエラーが表示されたり、されなかったりします。
こんな時は(Bluemix 環境だけのトラブルシューティングではありませんが)稼働中のアプリケーションのログを見るのが第一です。Bluemix の場合はダッシュボードの「ログ」を選択すると、アプリケーションの全ログを参照することができます:
ログが大量に出力されている場合はその TYPE や CHANNEL(標準出力/標準エラー)ごとに選別して絞り込むこともできます:
この例であれば、明らかな PHP エラーが出力されていることがわかるような行がありました。これをヒントに該当のソースコードを見なおして、何が原因だったのか?を推測して修正する、ということが可能になります:
この例の場合であれば up.php の 5 ~ 8 行目でまとめてエラーが出ていた、ということがわかります。ソースコードのこの辺りに原因が・・・という推測ができるわけです。後はソースコードを見て判断、ということになりますね。
以上をまとめると、Bluemix アプリケーション開発時のトラブルシューティングとしては以下のようになります:
1. Bluemix 側の異常ではないかを切り分け
2. プッシュ時のエラーはプッシュログを確認
3. プッシュ成功後のアプリケーション稼働時の問題はアプリケーションログを確認
ケースその1 Bluemix 側に問題が発生している
何よりもまず最初に調べる必要なのがこれです。Bluemix 側に原因があってうまくいかないのか、自分のコードやアクションに問題があるのか、という切り分けです。
Bluemix のランタイムやサービスが正しく稼働していない場合(あるいはメンテナンス中の場合)、その機能を使ったアプリは当然うまく動かなくなります。そのため、まずは Bluemix の稼働ステータスを確認してください:
https://status.ng.bluemix.net/
↑このサイトでデータセンターリージョン毎/ランタイム・サービス毎の稼働状態を確認することができます(近い将来のメンテナンス情報もわかります):
おおまかにはこのサイトの情報で充分だと思いますが、認証機能などの内部的な機能レベルでの稼動状態を調べるにはこちらを参照ください:
http://estado.ng.bluemix.net/
IBM DevOps Services などの外部サービスを併用して使っている場合は、それらの併用サービスについても確認が必要になります。例えば IBM DevOps Services の稼動状態はこちらで確認できます:
http://status.hub.jazz.net/
これら上記4つの URL はブックマークしておくことをおすすめします。
ケースその2 プッシュ(デプロイ)できない
Bluemix 側に特に異常がないにもかかわらず、自分の作ったアプリケーションコードのプッシュ(デプロイ)に失敗する場合は、コードや設定ファイルの内容そのものに間違いが含まれている可能性を疑う必要があります。
例えば cf ツールを使って push したらこんな感じでエラーが発生することがあります:
> cf push appname1 Updating app appname1 in org dotnsf@jp.ibm.com / space dev as dotnsf@jp.ibm.com... OK Uploading appname1... Uploading app files from: C:\tmp\appname1 Uploading 15.9K, 13 files Done uploading OK Stopping app appname1 in org dotnsf@jp.ibm.com / space dev as dotnsf@jp.ibm.com... OK Starting app appname1 in org dotnsf@jp.ibm.com / space dev as dotnsf@jp.ibm.com... -----> Downloaded app package (12K) -----> Downloaded app buildpack cache (3.9M) -------> Buildpack version 4.1.5 Traceback (most recent call last): : :
(中略)
: : ValueError: Expecting object: line 1 column 1 (char 0) Staging failed: Buildpack compilation step failed FAILED BuildpackCompileFailed TIP: use 'cf logs appname1 --recent' for more information
エラーが出てプッシュが FAILED になってしまいました。さてどうしましょう?
このようなケースではプッシュ時のログを参照するのがいいです。その方法は上記の最後に書かれているように、cf logs コマンドに "--recent" オプションを付けて実行することで(直近のログを)確認できます:
> cf logs appname1 --recent : : : 2015-12-01T09:53:08.75+0900 [STG/0] OUT Downloaded [file:///var/vcap/data/d ea_next/admin_buildpacks/ee88f28c-4afb-47c3-bc0f-db9ddc1ebb1d_6cbec4f53c789b674b c4f011895cfb0f72c4d3e0/dependencies/https___pivotal-buildpacks.s3.amazonaws.com_ php_binaries_trusty_composer_1.0.0-alpha10_composer.phar] to [/tmp] 2015-12-01T09:53:08.76+0900 [STG/0] OUT PROTIP: Include a `composer.lock` file with your application! This will make sure the exact same version of dependencies are used when you deploy to CloudFoundry. 2015-12-01T09:53:08.90+0900 [STG/0] ERR Loading composer repositories with package information 2015-12-01T09:53:09.51+0900 [STG/0] ERR Installing dependencies 2015-12-01T09:53:15.05+0900 [STG/0] ERR Nothing to install or update 2015-12-01T09:53:15.05+0900 [STG/0] ERR Generating autoload files : : :
この例だと composer の処理の中でエラーが発生しているようなメッセージが出力されていました。とすると、composer.json に間違いがあったのかな・・・と思って実際の composer.json ファイルを確認したらこんな内容でした:
{
閉じなければいけない大カッコが閉じられていませんでした。ケアレスミス! これが原因ですね。最後に "}" を追加してプッシュし直した所、エラーはなくなりました。これはあくまで一例ですが、プッシュ時のエラーに対してはプッシュ時のログを確認する、という対応が解決への近道になります。
ケースその3 プッシュしたアプリが正しく動かない
アプリケーションのプッシュ(デプロイ)には成功して、つまり Bluemix 上でアプリケーションが動いている状態になっていて、その上でアプリケーションが期待していたように動かない、ということがあります。コーディング内容と状態にもよりますが、画面にエラーが表示されたり、されなかったりします。
こんな時は(Bluemix 環境だけのトラブルシューティングではありませんが)稼働中のアプリケーションのログを見るのが第一です。Bluemix の場合はダッシュボードの「ログ」を選択すると、アプリケーションの全ログを参照することができます:
ログが大量に出力されている場合はその TYPE や CHANNEL(標準出力/標準エラー)ごとに選別して絞り込むこともできます:
この例であれば、明らかな PHP エラーが出力されていることがわかるような行がありました。これをヒントに該当のソースコードを見なおして、何が原因だったのか?を推測して修正する、ということが可能になります:
この例の場合であれば up.php の 5 ~ 8 行目でまとめてエラーが出ていた、ということがわかります。ソースコードのこの辺りに原因が・・・という推測ができるわけです。後はソースコードを見て判断、ということになりますね。
以上をまとめると、Bluemix アプリケーション開発時のトラブルシューティングとしては以下のようになります:
1. Bluemix 側の異常ではないかを切り分け
2. プッシュ時のエラーはプッシュログを確認
3. プッシュ成功後のアプリケーション稼働時の問題はアプリケーションログを確認