undistributed filesystem manager Hirugi

Perl

http://d.hatena.ne.jp/nekokak/20100308/1268037078
ここで書いた内容を管理するツールを書いてみた。

http://github.com/nekokak/p5-Hirugi

タイトルの通りundistributed filesystemです。

use Hirugi;
my $hirugi = Hirugi->new(
    {
        host => '192.168.1.13:7000',
        rules => +{
            image => '/test/image/%s/%s.%s',
        },
    }
);
# ファイルを登録
$hirugi->store_content($key => ['a','b','gif'], $data);
# reproxyさせるURLを取得
$hirugi->get_path($key => ['a','b','gif']);
# ファイルを削除
$hirugi->remove($key => ['a','b','gif']);

まぁ、ざっくりこんな感じです。
ルールを設定してそれにそってファイルを管理できるようにしています。

まぁ、普通であればMogileFSを使ったりすればいいと思いますが。

Re: Qudo をためしてみた

perl

http://d.hatena.ne.jp/tokuhirom/20100322/1269250840

良くない点について考えてみた。

ドキュメント

ないですね。これは人に使ってもらおうとするレベルではないので何とかしたいところ。

ワーカークラスをよみこまないと、クライアントが動作しないっぽい？

動作しません。
現在のQudoではworker毎にHookを設定できるためです。
クライアントがenqueueするときにworkerに設定されているHookを呼び出す必要があるため
現在のところクライアント側でワーカークラスを読み込む必要があります。

ただし、enqueueするのに重いworkerを読み込む必要があるのは
決定的に良くないので対処したいところ。

Hookを分けるためだけなので、クライアントを分けて管理できればいいだけなので
woker毎にHookを設定できなくても対処できるのでとりあえずはそうするかも。

ワーカークラスの登録を ->new 以外でやる方法がわからない

qudoのワーカーを動かすには以下のようにします。
この時のmanager_abilitiesにこのワーカーで動作させるワーカークラスを指定しています。

my $qudo = Qudo->new(
    databases => [+{
        dsn      => 'dbi:SQLite:/tmp/qudo.db',
        username => '',
        password => '',
    }],
    manager_abilities => [qw/Worker::Test/],
);
$qudo->work();

今回の指摘ではnewする時だけしかmanager_abilitiesを設定できないと使い勝手が悪いという話でした。
これは

my $qudo = Qudo->new(
    databases => [+{
        dsn      => 'dbi:SQLite:/tmp/qudo.db',
        username => '',
        password => '',
    }],
    manager_abilities => [qw//],
);
$qudo->manager->can_do('Worker::Test')
$qudo->work();

manager->can_doで動かすworkerを後で設定できるので問題は回避できると思います。

ということで、久々にQudoについて考えたのであった。
いろいろと指摘ありがとう。


（追記）
とりあえずWorkerでHookを指定する機能は外しました。
ドキュメントはぼちぼち。。。

簡単アクセス制限画像配信について

perl

画像を配信する仕組みを考えたとき、
htdocsに画像を配置してしまうとだれでも好きなだけアクセスできてしまいますね。
まぁ、サイトのデザインとかで使っている素材であればいいんですが
ちょっとしたアクセス制限をかけたい素材な場合、
普通にhtdocsに配置して公開すると問題なわけです。


そういうケースの場合は今までMogileFSをつかって
ファイルを管理していたのですが、諸事情によりmogileは使わないで
管理できないかというのを考えてみました。


要件としては

  • 素材の管理で冗長構成をとらなくてよい
  • アプリ側で認めたファイルだけ提供する

です


個人的にはPerlbalを良く使っているので
Perlbalでためしてみました。


処理の流れとしては、
sv.intraがサービスを提供しているvhostでユーザはこのvhostに対して色々リクエストを投げてくるとします。
sv.intraはplackにより127.0.0.1:5000で動いているとします。
perlbalがport:80でうごいているので、sv.intraにリクエストをなげると
Perlbalが127.0.0.1:5000にreverse_proxyします。
画像ファイルはPerlbalがサーブしており127.0.0.1:7000で待ち受けているとします。


sv.intraはユーザからリクエストがあれば、ユーザにその画像ファイルにアクセスしていいかどうかの判定を行い
画像にアクセスして良い場合はX-REPROXY-URLを返すとします。
Perlbalはsv.intraからうけとったX-REPROXY-URLをみて画像ファイルにreproxyする感じです。


Perlblaの設定ファイル的にはこうなります。

LOAD Vhosts

CREATE POOL intra_pool
       POOL intra_pool ADD 127.0.0.1:5000

CREATE SERVICE intra
    SET role            = reverse_proxy
    SET pool            = intra_pool
    SET enable_reproxy  = true
ENABLE intra

CREATE SERVICE http_server
    SET listen     = 0.0.0.0:80
    SET role       = selector
    SET plugins    = Vhosts
    VHOST sv.intra = intra
ENABLE http_server

CREATE SERVICE img_server
    SET listen         = 127.0.0.1:7000
    SET role           = web_server
    SET docroot        = /home/nekokak/imgs
    SET dirindexing    = 0
    SET persist_client = on
ENABLE img_server


sv.intraのコードはこんな感じです(適当です)
（Perlbal::Plugin::PSGIをつかってもいいかも）

use Plack::Builder;
builder {
    sub {
        # ここで色々ちぇっくするのですよ！
        # 画像にアクセスさせてよければX-REPROXY-URLする
        return [
            '200',
            [
                'Content-Type'  => 'image/gif',
                'X-REPROXY-URL' => 'http://127.0.0.1:7000/hoge.gif',
            ],
        ];
    };
};


こうしておけば、ユーザからは画像に直接アクセスすることができず、
sv.intra経由のreproxyでのみ画像ファイルにアクセスさせることができます。
あと、PerlbalじゃなくてもX-REPROXY-URLを解釈できるものであれば（nginxとか）利用可能です。


今思いついて、試して動いたので何か問題点が他にあるかも知れませんがいい感じじゃないかとおもっています。


ユーザが画像とか素材をuploadするケースを考えるとちょっとだるいかもしれませが、
こちら側が提供する画像の配信を管理するのではつかえるんじゃないかなとおもっています。

Yokohama.pm#05.5

perl

金曜日に行われたYokohama.pmでKamuiについて
発表させていただきました。

http://yokohama.pm.org/2010/02/yokohamapm-5.html
http://yokohama.pm.org/2010/03/yokohamapm-5-1.html

持ち時間１０分じゃボリューム的につらいすね。


発表資料は
http://nekokak.org/presen/yokohama06/
こちらにあります。


個人的にはWAFを探している人はCatalystを使えばいいと思います
ドキュメントもしっかりしてるし
利用ユーザも多いので問題があったときに相談出来る人が多いと思います。


個人的にKamuiを作ろうと思ったのは
なるべくMoose/Mouseに依存してないこと、
Sledgeが好きなのでSledgeぽくかけること
Catalystのようなattributeでdispatch tableをつくるのが嫌なので集中管理できるように
というのがあればなぁと思いつくりました。


まだまだ手直ししたいところはありますが、
業務でびしばし使い出しているので、そういう意味の実績はぼちぼちついてくると思います。


KamuiはMobile系のサイトが作りやすくなるように
デフォルトでMobile系のプラグインを用意しているので
Mobileサイトを作るときに参考にしてもらえたり、使ってもらえるとうれしっす。


次回は関内じゃなくて横浜でいい場所みつかるといいすね。

webアプリからircbotに話しかける方法

perl

今作ってる簡易TODO管理の仕組みでtaskが登録されたらircに通知されるようにしたかったので
サックリつくってみた。
仕組みとしてはircボットとして常駐しながら、json-rpcなserverもうごいているので、
json-rpcで発言したい内容をpostするだけです。

irchttpd.plを常駐させておいて、
Webアプリ側でpost.plでやってることをやらせるだけ。
１チャンネルしか対応してないけど十分なり。