「ホスティング」というテーマをもとに、2013/06/15開催された Hachioji.pm#29 で発表したLTのスライドに若干の手直し(不備の修正)をしたものです。

1. mod_perlで動く
アプリをどう置くか
尾形 鉄次 (OGATA Tetsuji)
Twitter: @xtetsuji
2013/6/15 Hachioji.pm#29 LT

2. 自己紹介
• 尾形 鉄次 (OGATA Tetsuji)
• Twitter: @xtetsuji
• Blog: http://post.tetsuji.jp/
• Apache mod_perlの研究がライフワーク？

3. テーマ：
ホスティング

5. あんまり
よくわからない

6. ISPの伝統芸能
• 10年以上前を思い返す
• 共用ホームページスペース
• 「Perl CGIが動きます」
• あれの原理はどうだったんだろう

7. ISPの伝統芸能
• chroot
• suEXEC
• Perl CGI
• FTP
• …
•ヤバい黒魔術ばかりだ！！！

8. 「伝統芸能」が進化
しなかった理由
• より自由度の高いレンサバやPaaSの台頭
• ASP型サービスやSNSのような出来合い
のものに興味が移る→自分で作る意味
合いがなくなる
• そしてISPもそこにコストをかけなくな
った

9. mod_perlのホスティングを
考えてみる
• Perl CGI高速化環境で見た場合、先ほど
と同じ伝統芸能をするハックが大変
• Perl CGI高速化環境(Registryファミリー)
は内部で仮想的な名前空間を作成する
から、Apache内でユーザごとの厳密な
環境の切り分けができない

10. コア部分を見る
• ModPerl::RegistryCooker (mod_perl2)
• Perl CGI高速化環境を提供している
Registryファミリーのスーパークラス
• 実際はVirtualHostと絶対パスのURLから
仮想的な名前空間を生成してコードの
コンパイル結果を入れているだけ

11. sub make_namespace {
my $self = shift;
my $package = $self->namespace_from;
# Escape everything into valid perl identifiers
$package =~ s/([^A-Za-z0-9_])/sprintf("_%2x", unpack("C",
$1))/eg;
# make sure that the sub-package doesn't start with a digit
$package =~ s/^(d)/_$1/;
# prepend root
$package = $self->namespace_root() . "::$package";
$self->{PACKAGE} = $package;
return $package;
}

12. みんな大好きPlackでは
どうなっているかな？
• PlackではPlack::Utilが *.psgi のコンパイル
を行っている
• 手法としてはmod_perlとまるで同じ！
• sprintf部分を見てください！
• Plack/Util.pmの該当部分を見てみよう

13. sub _load_sandbox {
my $_file = shift;
my $_package = $_file;
$_package =~ s/([^A-Za-z0-9_])/sprintf("_%2x", unpack("C",
$1))/eg;
local $0 = $_file; # so FindBin etc. works
local @ARGV = (); # Some frameworks might try to parse
@ARGV
return eval sprintf <<'END_EVAL', $_package;
package Plack::Sandbox::%s;
{
my $app = do $_file;
if ( !$app && ( my $error = $@ || $! )) { die $error; }
$app;
}
END_EVAL
}

14. 伝統芸能 meets Plack?
• VirtualHostとURLで動的にapp.psgiを読み
込んでユーザ切り分けするPlack環境は
可能か？
• mod_perlのPerl CGI高速化環境と同様の
理由で切り分けは難しい
• Perl(Plack)が使えるPaaSが増えてほしい

15. セキュリティ的には
• インタプリタが読んだ「パッケージ」
を読み出せればセキュリティ崩壊
• %INCで簡単にいけるんじゃない？
• PerlRun読み捨て環境でもモジュールに
ついてはmod_perlは同じ事情

16. 前回のPerlBeginnersで
• mod_perl2環境上でPlackを使ってapp.psgi
を動作させる方法の質問があって意外
• Plack::Handler::Apache2 を使う
• ウェブを検索してもplackupしてポート
をリバースプロキシする情報ばかりな
ので仕方が無いかなぁ∼

17. ＿人人人人人人人人人＿
＞ 根強いplackup信仰 ＜
￣^Y^Y^Y^Y^Y^Y^Y^Y^￣

18. Plack and mod_perl
• とはいえ、知られていないことは結構
意外だった。個人的に。
• mod_perl思想(ModPerl::RegistryCooker)
がPlack(Plack::Util)にも活きている感動
• plackupせずmod_perl上でapp.psgiを実行
するための利点もある

19. Plack and mod_perl
• plackupしたらポート開いてサーバ起動
• インフラ担当者「誰がどう監視するん
ですか？落ちたらどうするですか？」
• Apacheだけで完結するとインフラ担当
者を せる効果的に説得できる

20. ＿人人人人人人人人人＿
＞ 根強いApache信仰 ＜
￣^Y^Y^Y^Y^Y^Y^Y^Y^

21. Tribute of Mr. Miyagawa
• Miyagawaさん自身、超mod_perl Hacker
• 20世紀からmod_perl1のApache::Registry
によるPerl CGIの高速化についてトーク
している
• 当時のSledgeは、数少ないmod_perl教材
だったくらい(お世話になりました)

22. Plack and mod_perl
• mod_perlのPerl CGIがISPに見放されたの
と同じ理由でPlackのISPホスティングは
技術的に難しいというか面倒
• ファイルベースで app.psgi を読み込む
Plack::Handler::Apache2::Regsitry もある
けど、これを超ハックする？うーん

23. 最近のApacheでは
• VirtualHostごとにpreforkの子プロセスを
分ける方法もある(らしい)
• ユーザごとにサブドメインを動的生成
する仕組みを用意すればイケる？
• とはいえ興味深い仕事ではないなぁ…

24. お役立ち情報です
• 大人が直面する「環境の縛りプレイ」
• Plack入れる→インフラ担当者が不機嫌
になる超大量の依存関係
• 根強いApache(mod_perl)信仰を利用して
ModPerl::PSGIを作成中です！

25. ModPerl::PSGI
• 単に個人的な勉強という観点から、
PSGIの仕様書だけから書きだしてみた
• 車輪の再発明回避と驚き最小の原則を
考えPlack::Handler::Apache2を大いに参考
とするように方針転換した

26. Plack::Handler::Apache
2からの改善点
• ModPerl::PSGIはPlack::*の依存関係は無い
• URIとURI::Escape依存をApache2のC API
で置き換えたので早くなっているはず
• まだ(怖くて)GitHubにアップしていませ
んが、近日アップ予定、期待してね！

27. mod_perl大好き
• 最後のほう、ホスティングの話を放置
してmod_perlの宣伝をする身勝手さ
• Plack⊃PSGIであってPlack≠PSGIだよ
• ModPerl::PSGIの成果は実績が出来たら
Plackへcontribute予定

28. おがた先生の次回作
にご期待ください

29. ご清聴
ありがとうございました