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

この記事は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なのにしょぼい記事になってしまった、、