38
Cloud Foundry(v2)へアプリを載せかえよう

Cloud foundry(v2)へアプリを載せ替え

Embed Size (px)

Citation preview

Cloud Foundry(v2)へアプリを載せかえよう

名前

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動画

自己紹介

まずは前回の輪読会後の続報

前回の輪読会発表時までに討伐できなかった

loggregatorですが

討伐出来ました!

http://flic.kr/p/adCWp3

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はv2からherokuと同じ

buildpackを使っている

なのでheroku向けに作られたアプリなら比較的簡単に動くはず!

実際にやってみるとそう簡単にはいかない。。。

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

やはり既存のアプリを載せ替えるのには辛い。。。

と思っていた矢先に素晴らしいアプローチが

http://flic.kr/p/5WawQd

console-server

console-serverとは?

● Google GroupsでJames Bayerさんが紹介● gistに1ファイル分のソースサンプルだけが置か

れていた

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

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

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上で動かしていきましょう

まとめ

● 現行のCF上だとheroku向けに作られたアプリであってもログが確認しにくい関係で難易度が高い○ 今回の面白い発想の解決策により載せやすくはなりまし

○ 本家も意識していてDiegoではそのあたりを考慮したい

とgoogle groupsで話していた

○ 関連して?java以外にも力を入れる為pivotalのBuidpackチームが出来たそうです

■ https://www.pivotaltracker.com/s/projects/1042066