先日サービス終了が発表された livedoor Reader (LDR) のオープンソース/英語版の Fastladder を、とりあえず手元のサーバに導入して動かしてみた際の雑感メモです。
私の環境は CentOS 6 + MySQL 5.6 です。他の環境の方は適宜読み替えて下さい。なお現在は Heroku ボタンも付きましたから、雰囲気だけ見たい方はそちらがよさそうです。
リソース
導入条件
ruby
ruby 2.0 以上が必要のようです。
CentOS 6 の yum で入る ruby は 1.8 と超古いので動きません。ソースから入れるか、少し古くてよいなら RPM を作成して入れる方法もあります。
bundler を使うので導入しておきます。
sudo gem install bundle
ライブラリ
ImageMagick を入れておかないとエラーが出ます（現状では入れておいてもエラーはでます。後述）
yum install -y ImageMagick
データベース
SQLite で動きますが、ヘビーに使うならちゃんとした RDBMS を用意するのがいい気がします。ちなみに設定ファイルに MySQL は 4.1/5.0 推奨とありますが、これはおそらく情報が古いだけです。
デーモンを起動できる環境
ウェブアプリを起動する形態の VPS などでは難しいかもしれません。クローラはデーモンとして動作するので cron を仕込む必要はありません。クローラを cron として動かすケースも想定されているかどうかはわかりません。
サーバ環境
ざっくり 250MB から 300MB ほどのメモリが必要です。
インストール
適当なところにソースコードを clone します。
git clone git://github.com/fastladder/fastladder.git
git コマンドが無い場合は zip ファイルをダウンロードして展開します。
wget -O ./fastladder-master.zip https://github.com/fastladder/fastladder/archive/master.zip
unzip fastladder-master.zip
mv fastladder-master fastladder
Gemfile を編集します。
cd fastladder
vi Gemfile
JavaScript のランタイムが欠けているのでファイル末尾にでも追記します。node.js なども使えるようですがこれが定番とのこと。
gem 'therubyracer'
PostgreSQL を使わないのなら、次の行を削除しておきます。
gem 'pg'
ライブラリ一式を入れます。
bundle install
データベースの設定
設定ファイルを準備します。
SQLite
cp config/database.yml.sqlite3 config/database.yml
MySQL
cp config/database.yml.mysql config/database.yml
vi config/database.yml
production: 以下の username や password などをそれぞれ設定します。
初期化
テーブルを作成します。
RAILS_ENV=production bundle exec rake db:create db:migrate
サーバの設定
シークレットキー
認証用のシークレットキーを設定します。
bundle exec rake secret
表示された長い文字列を、次のファイルの production: の secret_key_base に設定します。
vi config/secrets.yml
デフォルトでは環境変数を参照するようになっていますが、運用を考えるといろいろ面倒なのでべた書きしたほうが楽です。
タイムゾーン
こうしておかないと日時が（UCT との差だけ）ズレる場合があるという話もあるようなので私は設定していますが、何もしないほうがいいかもしれません。もしかするとデータベースの種類によって動作に違いが出る可能性があります。
vi config/application.rb
config.active_record.default_timezone = :local
config.time_zone = 'Tokyo'
追記：上記設定で運用していますがフィードによって（？）ズレがあるようです。ひとまず何もせずしばらく運用してみることをお勧めしておきます。
ちなみに time_zone に設定可能な値の一覧は次のように参照できます。
bundle exec rake time:zones:all
アセット生成
スタイルシートや JavaScript ファイルなどを生成するようにします。
vi config/environments/production.rb
デフォルトは false になっているので true に変更しておきます。
config.assets.compile = true
起動する
クローラ
フォアグラウンドで起動しています。
bundle exec ruby ./script/crawler --environment=production
バックグラウンドで起動したい場合は --daemon をつけます。
ウェブサーバ
ここでは例としてポート 33000 で起動しています。
RAILS_ENV=production bundle exec rails server -p 33000
継続稼働させるならそれぞれ README にあるように foreman を導入するとよいでしょう。ちなみに私は daemontools を使っています。
既知の問題
いくつか気付いた点です。知識のある方ならすぐ直せると思います。
link カラムの長さが足りない
MySQL では link カラムなどの長さが varchar(255) しかないのでしばしば長さが足りずエラーになります。今時の MySQL の varchar 型は 255 文字制限はありませんので、とりあえず適当に増やしておきます。
alter table items modify link varchar(2048) not null default "";
本来ならソース上で変更すべきですが、rails を知らないので修正箇所がわかりません・・。
クローラが外部バイナリのパスを認識しない
/usr/bin/identify などのパスを見つけられないようです。$PATH をどうにかしてプログラムに認識させられれば解決するでしょう。
Crawler error: No such file or directory - identify
パスを見つけられないまましばらく運用すると数百のゾンビプロセスが量産されますから、app/models/feed.rb の 127 行目あたりを適当にいじって MiniMagick が動作しないよう変更するといいかもしれません。
XML Parser が見つからない
たまに適切な XML Parser が見つからないというクローラメッセージが出ます（feedjira ライブラリ）。もしかしたら parse できていないフィード（の形式）があるのかもしれませんので、巡回漏れフィードがないか要確認です。
Crawler error: No valid parser for XML.
OPML インポートが正しく動作しない
OPML をインポートすると、最後に出現する <opml> グループの中身しか参照されなかったり、逆に最初の <opml> のグループにすべて押し込められたりとへんな挙動をするので注意してください。グループ分けしていた場合、LDR からフォルダ構造を保ったままインポートするには工夫が必要です。（面倒ですがグループごとに opml ファイルを分けて、グループの数だけ import するのが確実）
guid タグを認識しない
<guid isPermaLink="true"> 形式でリンクを指定された記事では link カラムが空になります。
まとめ
ひととおり動作させることはできますが、まだ一般の使用には早い印象です。まとまったドキュメントもありませんし、現状ではトラブルをある程度自力で調査・解決する気のある人向きのプロダクトと言えそうです。とはいえ使用者が増えると上記のような問題もすぐ解決されるでしょうし、興味がある方はぜひ今のうちから試してみてください。