とある企業のPerlモジュール管理の歴史
とある企業のPerlもじゅーる管理すずきまさし / @masasuz1
View Slide
おまえだれよすずきまさし / @masasuz五反田の辺りにある中小web企業6月1日で5年目らしいアプリケーションとインフラの中間エンジニア(最近アプリよりに戻された)zsh / perl / mysql / Ubuntu / Debian2
とある企業のPerlもじゅーるかんり3
注意3年ちょい前に入社したのでそれ以前のことは歴史書(git)からひもといているので正確で無いです。git (+ git-svn)の歴史に刻まれていない、先史時代のことは分かりません。4
おおまかな歴史先史時代丸ごとrsync期Debian Package期carton期5
先史時代知りません2006年より前はさかのぼれませんFreeBSDが使われていたようです6
丸ごとrsync期Debian 32bitApache + mod_perl + Sledgesystem perlArcher7
丸ごとrsync期 cont..CPANプロジェクトをrsyncバイナリ含む8
プロジェクト数が少ない全て同じOS/arch全サーバで同じモジュールを使える!9
問題ディストリビューションのメンテ切れarchの差異64bitバージョン管理が煩雑10
Debian Package期Debian 32/64bit混在Apache + mod_perl + (Sledge orSplite)cpan-packagerでCPANモジュールをdeb化arch / dist 毎に作るArcher => Watch2::Deployer11
apt-localとapt-proxyサーバxx-cpan-perlというパッケージの依存パッケージに全perl deb packageを突っ込むdeploy時にapt-localのインデックス生成各サーバにssh => aptitude update &&aptitude safe-upgrade12
複数 dist/arch混在環境バージョン管理ができるように全プロジェクト同じモジュール!?13
問題カジュアルにパッケージ足しすぎ。カオス依存関係地獄全プロジェクトに影響プロジェクト数が増えてきた簡単にバージョン上げられない古のモジュールがはびこることに。。14
問題 cont..OS自動インストール時に全モジュールをインストールしてるのでOSインストールに超時間かかる全サーバに対してデプロイするので、台数に比例してデプロイに時間がかかるsystem のdeb packageとかぶるバージョンにepochを付与して回避(ダウングレード!)15
問題 cont..ディストリビューションをアップデートするたびに検証作業が必要。。特定のプロジェクトで新しいバージョンを使うことができないプロジェクト同居の可能性があるのでextlibに突っ込めない16
carton期Ubuntu Server 64bitcarton(Upstart +) Server::Starter + Starlet +Amon2OrePAN2::Servernot system perl独自ビルドしたdeb package17
cpanfile(.snapshot)に依存モジュールを記述carton install —deploymentプロジェクト毎に独自のモジュールが使える社内モジュールはOrePAN2に上げるsystem perlに依存しないdist変えやすい18
おおまかな歴史先史時代丸ごとrsync期Debian Package期carton期 <= イマココ19
正しい歴史先史時代丸ごとrsync期丸ごと(ry + Debian Package期丸(ry+Deb(ry or carton期<=イマココ20
CPANプロジェクトは最後の最後まで消えなかった更新が速い(設定系)モジュールが残り続けた社内モジュール置き場になった。21
新しいプロジェクトじゃないとcarton化しにくいApache + mod_perlからの移行が。。新規プロジェクトなら楽なので、そこから古(いにしえ)のモジュールの関係というか実際依存関係ぶっ壊れてる22
とはいえ、どのスキームも当時のコンテキストにはあっていた。レガシーなスキームが悪いのでは無く、コンテキストが変わってしまったのに、レガシーなスキームを使い続けるのが悪。23
なので、すぐには全部変えられないけど、少しずつ、時代に合わないものを消して行っている途中。大事なのは、問題は問題と認識して解決の方向に進めること。エンジニアだもの文句じゃ無く技術で解決しよう。24
おしまい25