Cloudn PaaSというサービスの開発を成功させるための、この1年の試行錯誤とその効果が内容です。スライドとtogetterを合わせてみるとだいたいの雰囲気はわかると思います。
プロジェクト運営やプロセス改善がメインの内容で、技術的な話は3割ぐらいと少なめです。これは、DevSumiの参加層をDevSumiの中の人である@kohseiさんにお聞きした上で決めました。

この発表における個人的な目標は、以下の2つでした。

Cloudn PaaSのこの1年ちょっとの開発を総括する内容にすること
自分たちのやり方が良いか悪いか、意見をもらえる内容にすること

後者の目標は、チームメンバから何回か、「このPJにいて楽しい」という話を聞いていたので少しは自信があるのですが、同時に、うまくプロジェクトを進められない限界を感じていたり、@ryuzeeさんのScrumの部分適用はダメという記事を見たりしていて、周りからはどう見えるのか、それを聞きたかったために存在します。

大事なのは、別にアジャイルやScrumを導入しようとしたわけではなくて、いいなと思ったやり方や、結果的にうまくいったやり方が、たまたまアジャイルやScrumであったことだと思っています。（なのでScrumの部分適応になるのは仕方ない、のかなぁ？？ちなみに、最近プロジェクトで、「アジャイルって結局なんなんすか？」っていじめられたりｗして自分でもよくわかんなくなってきたので、このスライドには「アジャイル」という単語は入っていません。アジャイルサムライにも、「アジャイルであるかどうかなんて、どうでもいいんだ」って書いてあるし、そうだと思うし！）

感謝1、コミュニティの先輩や仲間たちへ

ここから怒涛の感謝コーナーです。
まずはYokohama.rbのメンバを中心とした、コミュニティの仲間たちへ。

本番前、本番とTwitter上などで盛り上げてくれたこと
本番に、実際に来てくれたこと
終わったあと、どこが良かった、悪かったと指摘してくれたこと
他で質の高い発表をしていて、スライド作りのモチベーションをくれたこと

どれも本当にありがたかった！お前らありがとう。
中でも4.はすごい重要で、わざわざ来てくれている、かつ、Yokohama.rb Tシャツを着てプレゼンするのに、下手な販促セッションをやったら2度と正面から顔合わせられない、というのはすごい良いプレッシャーになりました。

あと重要なのは、日本で一番Cloud Foundryに詳しい@yssk22さんに指摘されるまで愚かにも気付いていなかったんですが、「コミュニティのみんなは、タイトルや発表内容が評価されて発表の機会を得た」のに対し、「今回の自分は、会社がお金を払ったから発表の機会を得た」という事実。この認識をごまかしたら生涯地を這う感じする。超重要。
次はどこかのRuby会議で技術的なことを話したい。技術あんまりないけど。

それから、1年前にScrumの練習を快く引き受けてくれた@nawotoさん、写真の使用を快諾いただいた@koichirooさん、おかげさまでなんとか発表を完走することができました、ありがとうございました。
@nawotoさんには発表報告のあと、Scrum Boot Camp The Bookにサインももらいました。やった！

本の内容は、取り上げられている事例があるあるで、とても良いと思います。まだ漫画の部分しか読んでいないけど…。キミちゃんかわいい。

感謝2、DevSumiスタッフへ

次に、DevSumiスタッフの方々へ。
いやもう、このような機会をいただけて本当にありがたかったです。特に翔泳社の岩切(@kohsei)さん、白羽さんには、発表者やタイトルの変更への対応だけでなく、経験に裏打ちされたたくさんのアドバイスをいただきました。

自分がDevSumiに初めて参加したのは2010年で、当時はこの人たちすげーなーと思うだけで、まさか3年後に話す方になるとはぜんぜんまったく予想していなかったのですが、それが実現したのは、その間DevSumiを継続したDevSumiスタッフの方々のおかげです。

感謝3、Cloudn PaaSの開発メンバーへ

最後に、Cloudn PaaSの開発メンバーへ。
今回の発表は、話したのは自分ですが、内容は完全に僕ら開発チームの発表です。

土日に怪しげな勉強会に行って影響受けてきた奴が「これとりあえずやってみようぜー」って言っているのを相手してくれて、ありがとう。まぁ、そういうメンバーを集めたんだけどね！(￣ー￣)ﾆﾔﾘでも想像以上にうまくいったのはお前らのおかげです。

メンバーそれぞれへの感謝は、また別の節目が来たら書きたいと思います。

反省会は週末の10th granpark.rbでやるよ！
こういう開発、もっと流行るといいよな。

2012-06-28

Heroku meetup #5に行ってきた。

メモ PaaS heroku

Heroku meetup #5に行ってきました。4月の#4以来。

毎度感じることなのだけど、Herokuの強さは、

自由競争下で改良の続くAddon群
ドキュメント・サポート体制

にあると感じる。ほんとすごい。

その他メモ

Wantedlyは2-3Web Dynos, Delayed Jobを使うworker, 有料DB, 有料New Relic, Logglyなどを利用
QA@ITは5Web Dynos, SendGrid, WebHook, Papertrail, Memcachier, New Relicなどを利用
月20,000dyno hours以上使うと、チーム機能、24時間サポート、コンサルなどの入ったEnterprise Packageが利用できる
独自SSL証明書を使うにはサポートに連絡する必要あるらしい
mixi2回目。きれい。

Meetupとか行ったらなるべくブログ書くようにしたいもんです。

2012-02-29

Cloud FoundryのアプリのログをFluentdで集めるというLTをした。

CloudFoundry Ruby

2/15のCloud Foundry JP Special Meetupで、Cloud Foundry上のアプリケーションのログをFluentdで集めるものを作ったよ、というLTをしました。

Collect Cloud Foundry App Logs with Fluentd

View more presentations from Katsunori Kawaguchi

VMwareのPatrick氏が来日されたので、英語で発表。アレな出来だったけど、Issue: I need to study Englishでウケたのでよしとする。英語はよしとしないで勉強するよ！

ちなみにTweetしてもらえたので、だいたい伝わった、はず。 https://twitter.com/#!/chanezon/status/169747900446941184

それから、CF Tシャツももらいました。https://twitter.com/#!/tnaoto/status/169771333016760321 写ってないけど、裏に"YOU BET YOUR PAAS IT'S OPEN"と書いてあるのがカコイイ。

LTの内容についてはそのうち詳しく話す予定。今のところVCAPとアプリには変更を加えないという方針で作っているけど、今後どうするかは悩みどころ。

2011-12-19

第3回 Cloud Foundry輪読会で発表した。 / そしてPaaSについて思うこと。

CloudFoundry Ruby

この記事はCloud Foundry jp Advent Calendar 2011の19日目です。ちなみに3周目です。。
前日は@r_takaishiさんのCloudFoundryは新規アプリケーションのデプロイ時に何をしているのか（和訳）でした。
明日は@y_wakaiさんの予定です。

12/15に某田町のビルで行われた第3回 Cloud Foundry輪読会で、dev_setupを利用した Cloud Foundry マルチノードセットアップという題でしゃべりました。

Cloud Foundry multinode setup using dev_setup(Chef)

View more presentations from Katsunori Kawaguchi

参加者20人のうち、dev_setup(Chef)を利用したことのある人が4〜5人だったので、スライドp.6の分岐は「Noが多い」の方に。後半が~~いつも通り~~駆け足になってしまったので、話の肝であるp.17〜20はまた別の機会に話したい＆意見交換したいなぁと思います。

テストを読みたい（各コンポーネントのフォルダにあるunit & functional testと、testsフォルダにあるcucumberで書かれたintegration test共に）
LTしたい
初心者セッションしたい

といったあたりが質疑と懇親会で挙がったので次回以降やりたいところ。各言語の定番アプリのカタログ化もあると便利かも。

そしてPaaSについて思うこと。

わずか8人で回したAdvent Calendarも、この3周目で自分の分はラストということで、最後にPaaSについて思うことを箇条書きポエムとして残しておきたいと思います。

Railsを使う自分にとっては、Herokuの登場後、プライベートの開発がとても楽になった
2011年はAddonも増え、仕事の開発環境よりプライベートの開発環境の方が良い、という逆転現象が起きた
ハードウェア故障の対応、年2回の停電への対応、ミドルウェア以下のセキュリティチェックへの対応、各種の申請が不要。ヘブン状態！
サービス開発に専念できる。集中の目標（byドラッカー）が立てられる
プライベートの開発環境の方が良いのは、PaaSだけの問題ではなくて、効率でメールを凌駕するグループウェアが利用可能なことも大きいかも
2012年もこの流れは変わらない
生存戦略を考えた場合、仕事の開発環境をプライベートの開発環境まで引き上げないとやばい
しかし、顧客情報などをPaaS上に置くことは（少なくとも今いる会社には）不可能
そこで社内でも構築できるCloud Foundry

2011-12-11

Cloud Foundryを複数ホストで動かした。その2 dev_setupを使う編

CloudFoundry Ruby

この記事はCloud Foundry jp Advent Calendar 2011の11日目です。ちなみに2周目です。
前日は@r_takaishiさんのStackatoとLXCによるクラウドにおけるセキュリティ（翻訳）でした。
明日は@y_wakaiさんの予定です。
ちなみにこの記事の内容は、12/15(木) 19:00〜の第3回 Cloud Foundry輪読会で詳しく話すつもりなので興味がある人は現地で僕と握手！

今回は、VCAPのdev_setupフォルダに入っているVCAPのセットアップスクリプトを使って、Cloud Foundryを複数ホストで動かす方法を書く。
元ネタ（作ろうとしてる構成は違うけど）はこちら→ Single/Multi Node VCAP Deployment using Chef

9月にもCloud Foundryを複数ホストで動かす方法を書いたが、VMwareの人も We've been working on a replacement for the vcap_setup script based on Chef. と言っているのでこちらのやり方の方が良い。

今回のホスト構成

今回構築を目指すのは上のような構成。
文量の都合から、利用者が数十人程度の小規模なPaaSを想定した際に一番重要になりそうな、DEA（PaaSに乗るアプリケーションを実行するコンポーネント）を横に並べることにフォーカスする。
ちなみに同様のやり方で、DEA以外のVCAPコンポーネントも別々のホストに分離可能。

この構成であれば、あるDEAがダウンした場合、Health ManagerとCloud Controller、他のDEAによって、障害の起きたDEA上にいたアプリケーションを自動的に復旧してくれる。そのあたりの挙動についての日本語情報は、CloudFoundryにデプロイしたアプリケーションの死活監視の仕組み1が詳しい。

dev_setupについて

で、dev_setupを利用してVCAPを動かす手順は、以下の通り。

Ubuntu Server 10.04の用意。gitのインストール(sudo apt-get install git-core)
VCAPソースコードのダウンロード(git clone)
セットアップに利用するconfigファイルの作成
dev_setup/bin/vcap_dev_setupを使った、VCAPコンポーネントのセットアップ
VCAPコンポーネントの起動

重要なのは3と4で、3でそのホストにセットアップするVCAPコンポーネントの設定を書いて、4でその設定に沿ったセットアップ作業をしている。
4のvcap_dev_setupの中では、システム管理ツールであるchefを使っている。ちなみにここで使っているchefは、chef-serverを必要としない、chef-soloの方。

3で作るconfigファイルのサンプルは、dev_setup/deployments/sample/ にあるので参考にすると良いはず。

1と2の作業は全ホストで共通なので、以下では3以降の作業について書く。なお、git cloneしたVCAPソースコードは/etc/cloudfoundry/vcap/にあるものとする。

ホスト4

先にホスト4から。（ホスト1=DEA1と末尾の番号を合わせるためにこんな構成に、、）
ホスト4のconfigファイルは以下の通り。domainは利用するドメインに変更する。serviceも必要に応じて変更する。

---
deployment:
  domain: "yourdomain.com"
  name: "rest"

jobs:
  install:
    - nats_server
    - ccdb
    - cloud_controller:
        builtin_services:
          - redis
          - mongodb
          - mysql
    - router
    - health_manager
    - redis_node:
        index: "0"
    - redis_gateway
    - mysql_node:
        index: "0"
    - mysql_gateway
    - mongodb_node:
        index: "0"
    - mongodb_gateway

これを/etc/cloudfoundry/rest.ymlとして保存し、bin/vcap_dev_setupの-cオプションで指定する。
あとはパスワードを聞かれる程度で、スクリプトがVCAPコンポーネントをセットアップしてくれる。

% cd /etc/cloudfoundry/vcap
% dev_setup/bin/vcap_dev_setup -c /etc/cloudfoundry/rest.yml
Checking web connectivity.
chef-solo is required, should I install it? [Y/n]

(中略)

* Status: Success
* Config files: /etc/cloudfoundry/.deployments/rest/config
* Deployment name: rest
* Note:
* If you want to run ruby/vmc please source the profile /home/vcap/.cloudfoundry_deployment_profile
* If you want to run cloudfoundry components by hand please source the profile /home/vcap/.cloudfoundry_deployment_local
* Command to run cloudfoundry: /etc/cloudfoundry/vcap/dev_setup/bin/vcap_dev -n rest -d /etc/cloudfoundry start

上のように Status: Success となればセットアップは成功。あとは最後の行を実行すれば、DEAを除くVCAPコンポーネントが起動する。

% /etc/cloudfoundry/vcap/dev_setup/bin/vcap_dev -n rest -d /etc/cloudfoundry start
router              :    RUNNING
cloud_controller    :    RUNNING
health_manager      :    RUNNING
mongodb_gateway     :    RUNNING
mongodb_node        :    RUNNING
mysql_gateway       :    RUNNING
mysql_node          :    RUNNING
redis_gateway       :    RUNNING
redis_node          :    RUNNING

ホスト1〜3

configファイルは以下の通り。

---
deployment:
  name: "dea"
  domain: "yourdomain.com"

jobs:
  install:
    - dea:
        local_route: "172.16.0.11"
        secure: "true"
  installed:
    - nats_server:
        host: "172.16.0.10"
        port: "4222"
        user: "nats"
        password: "nats"

注意点は、以下の3つ。

local_routeはホストごとに書き換える。上の例はホスト1の場合。
DEAの設定は、例えば以下のsecureの項目のように書く。設定可能な値はcookbookのdea.yml.erbを、デフォルト値はdefault.rbを見るとわかる。
nats_serverを指定する。今回の場合はDEA以外はホスト4の役割なので、ホスト4を指定する。nats_serverのportやuser, passwordはホスト4のconfigファイルで設定可能。

これを/etc/cloudfoundry/dea.ymlとして保存し、bin/vcap_dev_setupの-cオプションで指定する。
あとはホスト4の場合と同じ。

% cd /etc/cloudfoundry/vcap
% dev_setup/bin/vcap_dev_setup -c /etc/cloudfoundry/dea.yml
Checking web connectivity.
chef-solo is required, should I install it? [Y/n]

(中略)

* Status: Success
* Config files: /etc/cloudfoundry/.deployments/dea/config
* Deployment name: dea
* Note:
* If you want to run ruby/vmc please source the profile /home/vcap/.cloudfoundry_deployment_profile
* If you want to run cloudfoundry components by hand please source the profile /home/vcap/.cloudfoundry_deployment_local
* Command to run cloudfoundry: /etc/cloudfoundry/vcap/dev_setup/bin/vcap_dev -n dea -d /etc/cloudfoundry start

% /etc/cloudfoundry/vcap/dev_setup/bin/vcap_dev -n dea -d /etc/cloudfoundry start
dea                 :    RUNNING

動作確認

正しくセットアップできていれば、vmc pushしたアプリケーションが、ホスト1〜ホスト3に分散してデプロイされるようになる。デプロイされたアプリケーションは、/var/vcap.local に配置されているので、それを見ることで確認可能。

その他

vcap_dev_setupが途中で失敗した際は、エラーメッセージを見ながら作業することになる。gemがないとかgemがないとかで失敗しやすい。また、ホストが増えてくるとデプロイツールの整備も必要になる。その辺の話は15日にする…予定。

2011-12-04

Cloud Foundryの言語/フレームワークの判定ロジック

CloudFoundry Ruby heroku

この記事はCloud Foundry jp Advent Calendar 2011の4日目です。
前日は@r_takaishiさんのStackatoを使ってみたでした。
明日は@y_wakaiさんの予定です。
このままだと8日目で終わってしまうので、興味のある人は参加するといいんじゃないかな！
それから、12/15(木) 19:00〜の第3回 Cloud Foundry輪読会もよろしくです。

Cloud Foundryはたくさんの言語/フレームワークに対応しているが、アプリケーションの言語/フレームワークの判定ロジックをまとめたのが下記。vmc pushする際に[WARNING] Can't determine the Application Type.と言われたら見るといいはず。
数日前に、herokuでの言語/フレームワークの判定についての日本語記事が出ているので比較するのもいいかも。

優先度	言語/FW	判断ファイル
1	Rails	config/environment.rb
2	(Java系)	*.war または WEB-INF/web.xml
2a	Grails	2 かつ WEB-INF/lib/grails-web*.jar
2b	Lift	2 かつ WEB-INF/lib/lift-webkit*.jar
2c	Spring	2 かつ WEB-INF/classes/org/springframework/ など
2d	Javaweb	2 かつ 2a〜2c以外
3	Sinatra	sinatraをrequireしている *.rb
4	Node.js	server.js, app.js, index.js, main,js のうち1つ以上
5	PHP	*.php
6	Erlang/OTP Rebar	reloases//.rel, releases//.boot の両方
7	Django	manage.py, settings.py の両方
8	WSGI	wsgi.py

現状、この判定はCloud Foundryのクライアントであるvmc側で実装されていて、ソースは https://github.com/cloudfoundry/vmc/blob/master/lib/cli/frameworks.rb になる。ソースが見られるのは、OSSであるCloud Foundryのいいところ。
このファイルには、各言語/フレームワーク別に標準のメモリ使用量も設定されていて、Java系はやっぱり多いなぁとか、Rails3が256MBなのにDjangoは128MBとか面白い。

サーバ側にも、stagerのmanifestファイルにdetectionフィールドがあるけど、現時点では言語/フレームワークの判定には使っていない、はず…

なぜこれを調べたかというと、7つの言語7つの世界で興味を持ったscalaのフレームワーク、liftのサンプルをvmc pushしようとしたら、liftアプリとして認識されずはまったため…。ちなみにそのアプリは無事動いています。 http://lifttest.cloudfoundry.com/

うーんAdvent Calendarなのにしょぼい記事になってしまった、、