Upload
takeshi-morikawa
View
1.179
Download
0
Embed Size (px)
Citation preview
名前
morika-t or morikat or 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動画
自己紹介
traffic_controllerからloggregatorに接続しに行く際の設定値が
traffic_controller自体のポート番号と同じ番号に対してloggregator_serversのIPに接続しようとする作りになっていた為
修正された箇所
https://github.com/cloudfoundry/loggregator/blob/master/src/trafficcontroller/trafficcontroller/main.go#L36-L43
cf_nise_installer(All-in-One)で動かなかった理由
Cloud Foundry上でアプリを動かす際に苦労する所
● staging処理や起動までの間で死ぬとログがあまり得られなくて辛い
● デプロイした後での環境もどういう構成かユーザサイドからは見えないのでデバッグしにくい
なぜ辛いのか?
Cloud Foundryでは。。。
● アプリが起動に失敗するとコンテナが破棄される
● アプリが出力したログ(なぜ動かないかのヒント)が入手出来ない○ ローカルではそのままでは動かなくてもエラーを頼りに
解決できるのが一般的
● buildpackも含めてそもそもコンテナ内部でどういう挙動になるのか分かりにくい
Loggregatorで見えるログの範囲
1. staging時(buildpackの処理)⇒見える
2. 起動時⇒v156あたりからバックグラウンドでcf logsすると見える
https://github.com/cloudfoundry/loggregator/commit/40aabec67fd1fa59322396c8792ca2a76d10f1b3
3. 起動後⇒以下は見えるRTR(アクセスログ)
stdout(アプリの標準出力)
stderr(アプリの標準エラー出力)
※載せ替えの際はstagingのみならずstartingのログが重要となる
どうすると利用者(AP開発者)にとってヒントになるのか?
● 例1アプリが死んだ後コンテナ内部のログをダウンロード出来る仕組みなど
これができるだけでもだいぶ違うかも?
● 例2○ ユーザがコンテナ内部の挙動を把握しアプリを配置
■ 何らかの方法でコンテナ内部に入って確認■ herokuで使えるらしいsshのようなイメージ
● 例3○ warden+buildpack部分を簡単に試せるようにする
■ Dockerfile位にカジュアルに使えると良い■ All-in-OneだとAP開発者にとっては結局色々面倒&BOSH-liteは手
軽じゃないので個人的にはこの解決方法を模索したいと考えている
Grails Debug Console
特長BuildConfig.groovyに『compile ":console:1.3"』と記述して
cfのpush後、/consoleにアクセスするだけ
欠点● Grailsのアプリにしか使えない● Staging処理などで死ぬと使えない
http://morika.ng.bluemix.net/console
console-serverの動作の仕組み
● 内部的にはメインで動かすアプリに対して8080へReverseProxyする
● 本来動かすアプリは8080で起動するようにする事
● WebSocketを使いコンソールのやりとり
console-serverの使い方
● go build ./...等を使い実行ファイル形式にする● debugしたいアプリのフォルダに格納する● -cで起動オプションを指定
○ cfコマンドの場合は--command○ gcfの場合は-cで指定してあげる
○ main-processの部分は本来動作させるアプリを指
定する
例:-c “./console-server -console-process='bash' -main-process='hello-go''アクセスは/cfconsole
console-serverの注意点等
● All-In-One環境などでSSL環境でない場合はソース中のwss://のアドレス部分をws://hogehoge/等に変更する
● あくまでもCF的に動作していなくてはいけないプロセスはconsole-server自体であるため、呼び出した先のプロセスが落ちた場合はおそらくそのままになる(あくまでもデバッグ用途)
● 現状認証機構が存在していない為、cfconsoleにアクセスすればだれでも内部情報が見れてしまう
danhighamさんという方のアプリ
https://gist.github.com/danhigham/8970438
BlueMixでデプロイしたURLhttp://hello-go.ng.bluemix.net/cfconsole
console-server.go
cf-debug-toolsとは?
● Goのツールが公開された後にgoogle groupで紹介
● bashのスクリプトとwebsocket用バイナリからなる
● cfが動作可能なsinatraアプリのディレクトリ等で--commandに起動コマンドを与えると単独で起動する
● アクセスは/bash.shにアクセスする
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'
cf-debug-toolsの注意点等
● このアプリ自体も認証等が存在しないのでやはりあくまでも暫定的な策
● Google Groups上でDr Nic氏やIBMの方もイイね!な雰囲気でしたがJamesさんいわく、Pivotalのメンバーが作った物だけれど個人的なプロジェクトで作ったものなので~という事らしい
● 割とこのアプリを気に入った他の人がこのアプリのライセンスどないなってるんや?というコメントを残し、後日ライセンス明記された模様
Daniel Mikusaさんという方のアプリ
https://github.com/dmikusa-pivotal/cf-debug-toolsBlueMixでデプロイしたURL
http://cf-debug-tools.ng.bluemix.net/bash.sh
cf-debug-tools
volpe28vさんという方のアプリ
https://github.com/volpe28v/DevHub
BlueMixでデプロイしたURLhttp://cf-devhub.ng.bluemix.net/
DevHub
同じくvolpe28vさんのアプリ
https://github.com/volpe28v/kanban-list
BlueMixでデプロイしたURLhttp://cf-kanban-list.ng.bluemix.net/
kanban-list
本家
https://github.com/malclocke/fulcrumStackatoカスタム版
https://github.com/Stackato-Garage/fulcrum BlueMixでデプロイしたURL
http://fulcrum.ng.bluemix.net/
Fulcrum
● 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の例)
まとめ
● 現行のCF上だとheroku向けに作られたアプリであってもログが確認しにくい関係で難易度が高い○ 今回の面白い発想の解決策により載せやすくはなりまし
た
○ 本家も意識していてDiegoではそのあたりを考慮したい
とgoogle groupsで話していた
○ 関連して?java以外にも力を入れる為pivotalのBuidpackチームが出来たそうです
■ https://www.pivotaltracker.com/s/projects/1042066