最近、弊社でもいくつかのサービスでStarmanが動き始めてます。リソース監視厨としてStarmanやStarletといったPreforkなPlackサーバにおいてもApacheのmod_status同様、使用されているプロセス数、アイドル中のプロセス数を当然知りたいわけです。CloudForecastでグラフにしたいわけです。 すでにcho45氏がその機能を実現しています。cho45++です。ただ、ステータス表示を行うMiddlewareの他にステータス情報の変更を行うためにStarmanやStarletの本体に手を入れており、若干使いにくいという印象を持っていました。そこでMiddlewareだけで、Middlewareのできる範囲でステータスを変更・表示するPlack::Middleware::ServerStatus::Liteを書いてみました。ソースコードはgithubにpush

P::App::WrapCGI は、perl でかいた CGI しか実行できないので、ちゃんと exec してうごく一般的な CGI がうごくようにしてみる施策。 環境変数をセットアップして、双方向パイプで IPC しているだけです。 diff --git a/lib/Plack/App/WrapCGI.pm b/lib/Plack/App/WrapCGI.pm index 7f0a7a7..0ce15d6 100644 --- a/lib/Plack/App/WrapCGI.pm +++ b/lib/Plack/App/WrapCGI.pm @@ -2,7 +2,7 @@ package Plack::App::WrapCGI; use strict; use warnings; use parent qw(Plack::Component); -use Plack::Util::Acc

拡張性等を考慮しなければ、以下のように簡単にかくことができる。 View を XSlate きめうち。ルータは given-when で、設定ファイルは .pl という構成。だいたいのウェブアプリケーションは、これぐらいの機能の WAF で十分。ルーター部分は Router::Simple とかにさしかえた方がよいかもだけど。 5年前に Python で似たような記事をみたのだが、今はみんなのがんばりによって Perl でもおなじことができるようになった。 use strict; use warnings; use 5.10.1; package MyWAF; use parent qw/Class::Data::Inheritable/; use Path::Class; use Text::Xslate qw/mark_raw/; use Encode; use Time::Piece

CPANでPlack関連の情報はないかと漁っているとstarmanライクなPSGI仕様のサーバ Starlet があると聞いて早速ためしてみました。 http://search.cpan.org/dist/Starlet/ 今まで自分の所ではplackで利用できるWAFを自前で書いてそいつをStarman + Server::Starterを使ってで動かしていました。 Starmanでなにも問題なく動いてるので変更する意味はないのですがPSGI仕様のいい所（簡単にインターフェースを取り替えられる）を利用させてもらいちょっとだけ試してみました。 変更前の環境はフロントにlighty(mod_proxy)＋バックにStarman,Server::Starterな構成です。でStarmanはdaemontoolsで起動させてます。 変更前 starman利用時のdaemontoolsのrun-s

Plack::Server::Standalone 系を使ってウェブアプリケーション開発と運用が楽になる話 - JPerl Advent Calendar 2009 Perl に関するちょっとした Tips をのっけてみるよ。ちゃんと続くかな？ 既存の環境に対する不満 Perl のウェブアプリケーションを構築するにあたっては、リバースプロキシと mod_perl を組み合わせるか、あるいは FastCGI (ExternalServer) を利用するのが一般的だと思います。しかし、どちらをとっても、環境を構築して設定するのが難しいというのが個人的な不満でした (mod_redirect を設定したり mod_fastcgi にパッチをあててインストールしたり startup.pl を書いたり...)。自分が Plack の開発 (主に Server::Standalone と Server

最近のwebセキュリティ界隈ではCSRFやDNS-Rebindingが話題ですが、Plackでアプリケーションサーバを立ち上げる際にこれらの対策をどのように行うかについてまとめてみました。 まず、CSRF対策ですが、拙作のPlack::Middleware::RefererCheckを使うことにより、RefererのチェックによるCSRF対策が行えます。CSRF対策としては、onetime token方式も存在しますが、個人的にはRefererチェックが導入が楽で好きではあります。Refererを送信しないクライアントを対象にしたサービスを運営される方は別途onetime token方式の対策をおこなってください。 Plack::Middleware::RefererCheckの使い方はこのようになります。(SYNOPSYSからの抜粋) use Plack::Builder; builde

Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

今年も残り僅かです。今年のPerl界の最大の話題は何と言っても宮川氏のPSGIとPlackでしょう。今年後半に出現したからかも知れませんが、残りの話題なんて完全にどうでもいいガラクタのように思えてなりません。しかしながら、私個人がその凄さを認識したのは、Simon Cozens氏のエッセイ”I finally get PSGI and Plack!”を読んでからです。元々、流行り病や最先端病には罹らない性格ですので、人より完全に遅れています。（こういうことを書くと周辺から突っ込みがあるかも知れませんので、予防線のために書いておきます。私がやたらとMo[ou]seを推奨しているのは最先端でも何でもないのです。Mo[ou]seが出現して何年経っているかを考えればとうに旬や物珍しさを過ぎており、悪い言葉で言えば姥桜ですよ。そして、何回も書きますが、Perl初心者や未熟者にこそ勧めているのであって

Plack::Middleware::Headerをgithubに上げました。 これは、Plack::Middlewareレイヤーでレスポンスヘッダを設定するもので、Apacheでいうところのmod_headersに相当します。 使い方はこんな感じです。 use Plack::Builder; builder { enable 'Header', set => ['X-Plack-One' => '1'], append => ['X-Plack-Two' => '2'], unset => ['X-Plack-Three']; $app; }; 自分はPlack::Middleware::Staticと併用してExpiresをつけたりするのに使うために作りました。IEがExpires: -1とかやっておかないとしばらくキャッシュしてIf-Modifled-Sinceなリクエストも投げてく

Preforkした上でAnyEventのloopを動かすPlack::Server::AnyEvent::Preforkを、先週のPlack Hackathonの時間で形にしてgithubにpushしました。 はなぼくろ師との共作です。 目的は、AnyEventでもマルチコアを使いたいよねという理由ですが、それほど一般的な利用はないと思います。plackupの方でprefork処理を行うとかいう話もあったりなかったりなので、しばらくCPANにはアップロード予定ありません。不足している部分もありますので、fork & patchウェルカムです Hello Worldだけのテストで生AnyEventとの比較 ベンチマークをしたサーバはVMware ESXi上の仮想マシン。一応CPU 2つ割当てある 起動はこんな感じ plackup -a hello.psgi --server AnyEvent

bulknews.typepad.com Tatsuhiko Miyagawa's blog to discuss mostly tech and nerdy stuff. When you use middleware components in your PSGI app with Plack, you often want to enable them conditionally based on runtime environments. For example, some administrative middleware like debug-toolbar or stacktrace should be enabled if it's accessed from your office network, and js/css-minifying middleware and

PSGI/Plackにおいて、非同期にレスポンスが返せるstreamingという仕様/機能が追加されました。 PSGI/Plack streaming is now complete これを使うと、streamingをサポートしたサーバから非同期/nonblockingにhttpやGearmanを利用して外部へ問い合わせを行い、その結果をレスポンスしたりできます。 また、これがPlackで既に実装済みなので、非常に短いコードでサーバの実装ができちゃいます。 すばらしいですね。 すでにmiyagawaさんが、この機能を利用した非同期Web Framework「Tatsumaki」を書かれています。 イベントを扱う部分が隠蔽されているので、これを使うとさらに簡単に実装できます。 すばらしすぐる。 ここでは、簡単に外部へAnyEvent::HTTPを用いて、HTTPリクエストを行うサンプルを書い

Plack::Requestにhost無いなぁ。と思って勢い余ってforkしてコミットまでしてしまったのですが、#perl-casual@freenodeで呟いたところyappoさんから $req->uri->host もしくはURIオブジェクトの作成コストが気になるなら($req->uriは遅延作成なので) $req->env->{HTTP_HOST} でいいじゃんと言われました。確かにその通りですね。