2008年4月19日土曜日

CentOS5にPassenger(mod_rails)を入れる

Passengerの評判が良さそうなので、実際にRailsを運用しているサーバ(CentOS5)に入れてみた。

Passengerの良いところ

  • デプロイが簡単。railsのインスタンスは何個でポートは何番から当てて、フロントはリバースプロキシとかなんとかは、もう悩まなくていい。
  • mongrelとかthin並み、またはそれ以上速いらしい。(でも自分で公開しているベンチマークだからね。。。)
  • この仕組みであればcapistranoに対応できる。てかscript/spinを起動しないだけ。
  • passenger自体のインストールも簡単。CentOS5で、railsの動作環境は既に済ませてあれば3分で設定完了。
  • バーチャルホストを増やしたいときは、apacheのVirtualHostディレクティブに最低3行書くだけ。
  • deveropment環境なのかproduction環境なのかをapacheのconf上で指定できる。(たぶんまだオプションありそう)

Passengerの悪いところ

  • たぶんコイツメモリ大食い(そういうビジネスモデルなのかも)
  • 逆に、ポート何番は既に使っていて、インスタンスは何個立ってるとか、細かいチューニングは出来ないんだろうな…(未確認)

railsが動く環境は整っているものとする。

1.passenger自体のインストール

# gem install passenger

でgemを入れて

2.モジュールのコンパイル

# passenger-install-apache2-module

でモジュールをコンパイル

参考 本家のインストール手順

で、たぶんAPRとかなんとかが無いと怒られるので、メッセージ通り

# yum install httpd-devel apr-devel

とやると、コンパイル通ると思う。


3.apacheに設定追加
自分の場合は/etc/httpd/conf.d/passenger.confを作って、
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-1.0.1/ext/apache2/mod_passenger.soRailsSpawnServer /usr/lib/ruby/gems/1.8/gems/passenger-1.0.1/bin/passenger-spawn-serverRailsRuby /usr/bin/ruby

<VirtualHost *:80> ServerName target-domain-name DocumentRoot /var/www/domains/target-domain-name/rails-project/current/public RailsEnv production CustomLog /var/log/httpdtarget-domain-name.passenger_access.log combined ErrorLog /var/log/httpd/target-domain-name.passenger_error.log</VirtualHost>
としてから、apacheを再起動したらちゃんと動きました。(デフォルトのhttpd.confだと/etc/httpd/conf.d/*をすべてインクルードするはず)
あー、こりゃ便利だわ。まだ使い始めだからマイナス面が見えないけど、しばらく実運用して様子を見よう。
ちなみに、MacOSだと標準で入っているapacheと相性が悪いらしく、別途apacheを入れる必要がある。(MacPortsのapacheを使ってpassengerを動作させる方法を知ってる方連絡ください)
最後にPassengerで確認したい要点(何かわかったら追記する)
  • メモリ使用量
  • ソース修正時に再起動が必要か否か(ドキュメントに書いてありそうだけど)
  • インスタンスの落ちやすさ。
  • 各種railsバージョンやプラグインとの相性(問題ないと勝手に思ってるけど)
  • 外部からの死活確認の必要性。また再起動の方法。(apacheの再起動になるのかな?)

やっぱり動作モデルを理解するのが、理解が速いのかな。


2008年4月7日月曜日

rubyでスクレイピングまとめ

スクレイピングって、あれね。

HTMLなどから特定条件で文字を取得するやつね。

昔はなんらかの言語のHTTPライブラリと正規表現を使ってガリガリ書くのが多かったんだけど、最近はスクレイピング用のアプリケーションとか、専用ライブラリも出てきたんで、ちょっとまとめてみました。

条件は

  • プログラムを書く必要があるならRubyにする
  • プログラミングが必要ないなら、それが一番(データを取り出して終わり)
  • 特定ワードで検索して、検索結果からデータ取り出しってのを繰り返す
  • もちろん日本語を扱う

で、候補に挙がったのは以下の4つでした。

■web-harvest

  • Javaアプリ。
  • プログラミングの必要が無い。その代わりにXMLで条件を指定する。
  • 本家
  • MOONGIFTでの紹介記事
  • 本家の翻訳記事?
  • プログラミグの必要がないのはいいけど、きっとXMLだけの設定だとできないことがある気がする。(感覚値)
  • 英語版アプリしかないもので、日本語を扱うのはかなり不安。(UTF8だけならまだしも、まだSJISとかEUCあるよね)
  • ぐぐった限りでは、日本人ユーザいなさそう。もちろん日本語情報源無し。(2008/4/6現在)
  • ダメポと判断

■scRUBYt!

  • HTTPでの接続から、リンクのクリックやスクレイピングまでフォロー。
  • DSLっぽく書ける感じ。
  • 型にハマるなら、ちょー簡単に取得できる。
  • Hpricotを必要とする。
  • 本家
  • @ITの紹介記事
  • Rubyライブラリなので、KCODEさえ入れておけば日本語は大丈夫と判断。
  • ちょー簡単にまとまるので、とりあえずやりたいことがこのライブラリのサポート範囲内かどうかを検討するべき。
  • Hpricotを使っているので、Hpricotの上位に位置するのかと言えば、そうでもなく、作者曰く「使い分け」らしい。scRUBYt!は高機能で少ない手順でいろいろなものを、というスタンスなので、細かく制御したかったらHpricot+WWW::Mechanizeなんでしょうね。

■Hpricot

■scrAPI

  • Rubyのライブラリ。
  • フィルターっぽくあらかじめ欲しいものが決まっているときは便利なのかも。
  • 紹介記事
  • いまいち?

てな感じにまとまって、結局仕様が許すならscRUBYt!、自分で細かく制御したいならHpricot+WWW::Mechanizeという結論になりました。

さーつくってみよー