Downloaded 19 times
Uploaded byTakeshi Morikawa
Cloud foundry(v2)へアプリを載せ替え
Cloud foundry(v2)へアプリを載せ替え 第17回 cloud foundry 輪読会【リベンジ】資料
Cloud foundry(v2)へアプリを載せ替え
- 1.
- 2. 名前 morika-t or morikator morika_t 普段の業務 Cloud Foundry関連 最近のCloud Foundry関連の興味 Diego(hm9000に続くGoコンポーネント） ● DEAのdirectory server以外が主にGo化されている 割と最近は本家で開発が活発なので半年以内くらいに来るのでは？と予想 Decker(Cloud Foundry + Docker） ● CloudCredoの動画(http://youtu.be/QslNszh3jfY) dockerfileをpushするとcf上で動いているように見える youtube動画 自己紹介
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. Cloud Foundry上で アプリを動かす際に苦労する所 ● staging処理や起動までの間で死ぬとログがあ まり得られなくて辛い ●デプロイした後での環境もどういう構成かユー ザサイドからは見えないのでデバッグしにくい
- 13. なぜ辛いのか？ Cloud Foundryでは。。。 ● アプリが起動に失敗するとコンテナが破棄される ●アプリが出力したログ（なぜ動かないかのヒント）が入手出 来ない ○ ローカルではそのままでは動かなくてもエラーを頼りに 解決できるのが一般的 ● buildpackも含めてそもそもコンテナ内部でどういう挙動にな るのか分かりにくい
- 14. Loggregatorで見えるログの範囲 1. staging時(buildpackの処理） ⇒見える 2. 起動時 ⇒v156あたりからバックグラウンドでcflogsすると見える https://github. com/cloudfoundry/loggregator/commit/40aabec67fd1fa59322396c8792ca2 a76d10f1b3 3. 起動後 ⇒以下は見える RTR（アクセスログ） stdout(アプリの標準出力） stderr（アプリの標準エラー出力） ※載せ替えの際はstagingのみならず startingのログが重要となる
- 15. どうすると利用者（AP開発者）にとって ヒントになるのか？ ● 例1 アプリが死んだ後コンテナ内部のログをダウンロード出来る仕組みなど これができるだけでもだいぶ違うかも？ ● 例2 ○ユーザがコンテナ内部の挙動を把握しアプリを配置 ■ 何らかの方法でコンテナ内部に入って確認 ■ herokuで使えるらしいsshのようなイメージ ● 例3 ○ warden+buildpack部分を簡単に試せるようにする ■ Dockerfile位にカジュアルに使えると良い ■ All-in-OneだとAP開発者にとっては結局色々面倒＆BOSH-liteは手 軽じゃないので個人的にはこの解決方法を模索したいと考えている
- 16.
- 17. Grails Debug Console 特長 BuildConfig.groovyに『compile":console:1.3"』と記述して cfのpush後、/consoleにアクセスするだけ 欠点 ● Grailsのアプリにしか使えない ● Sｔａｇｉｎｇ処理などで死ぬと使えない http://morika.ng.bluemix.net/console
- 18.
- 19.
- 20.
- 21. console-serverとは？ ● Google GroupsでJamesBayerさんが紹介 ● gistに1ファイル分のソースサンプルだけが置か れていた
- 22.
- 23. console-serverの使い方 ● go build./...等を使い実行ファイル形式にする ● debugしたいアプリのフォルダに格納する ● -cで起動オプションを指定 ○ cfコマンドの場合は--command ○ gcfの場合は-cで指定してあげる ○ main-processの部分は本来動作させるアプリを指 定する 例： -c “./console-server -console-process='bash' -main-process='hello-go'' アクセスは/cfconsole
- 24. console-serverの注意点等 ● All-In-One環境などでSSL環境でない場合はソース中の wss://のアドレス部分をws://hogehoge/等に変更する ● あくまでもCF的に動作していなくてはいけないプロセスは console-server自体であるため、呼び出した先のプロセス が落ちた場合はおそらくそのままになる（あくまでもデバッグ 用途） ●現状認証機構が存在していない為、cfconsoleにアクセスす ればだれでも内部情報が見れてしまう
- 25.
- 26.
- 27.
- 28. cf-debug-toolsとは？ ● Goのツールが公開された後にgoogle groupで紹介 ●bashのスクリプトとwebsocket用バイナリからなる ● cfが動作可能なsinatraアプリのディレクトリ等で--command に起動コマンドを与えると単独で起動する ● アクセスは/bash.shにアクセスする
- 29. cf-debug-toolsの素敵な部分 ● -cの部分に本来動かしたいアプリ ||スクリプト起動コマンド という記述をすると前者が落ちた後に起動する ● その為、事前準備が不要 例： -c ‘bundle exec rails server --port=$PORT || curl -s https://raw.github. com/dmikusa-pivotal/cf-debug-tools/master/debug-console.sh | bash'
- 30. cf-debug-toolsの注意点等 ● このアプリ自体も認証等が存在しないのでやはりあくまでも 暫定的な策 ● GoogleGroups上でDr Nic氏やIBMの方もイイね！な雰囲 気でしたがJamesさんいわく、Pivotalのメンバーが作った物 だけれど個人的なプロジェクトで作ったものなので～という 事らしい ● 割とこのアプリを気に入った他の人がこのアプリのライセン スどないなってるんや？というコメントを残し、後日ライセン ス明記された模様
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. ● manifest用のstackatoファイルの削除 ○ 自分の環境用のmanifestでない為 ●Gemfileでsqlite3を入れるようにGemfileを書き換える ○ BlueMix上では利用可能だが検証時の環境はAll-in-OneでPostgreSQLな どがないので ● set-envでDATABASE_URLを指定（sqlite3://db/development.sqlite3) ○ 内部的に上記の環境変数でrakeタスクを動かすので ○ -cや--commandの最初の部分で指定して動くのでは？と思いましたが staging処理時点では評価されていないのでダメでした ● enviromentsにconfig.action_mailer.raise_delivery_errors=falseを追加 ○ herokuではsendgridが使えるそうですが今回は無い為 ● 起動時のオプション ○ 'bundle exec rake fulcrum:setup db:setup && bundle exec rails server --port=$PORT' 主な変更点（Fulcrumの例）
- 37.
- 38. まとめ ● 現行のCF上だとheroku向けに作られたアプリ であってもログが確認しにくい関係で難易度が 高い ○ 今回の面白い発想の解決策により載せやすくはなりまし た ○本家も意識していてDiegoではそのあたりを考慮したい とgoogle groupsで話していた ○ 関連して？java以外にも力を入れる為pivotalの Buidpackチームが出来たそうです ■ https://www.pivotaltracker. com/s/projects/1042066