$30 off During Our Annual Pro Sale. View Details »

2014-06-11_gotanda.pm

 2014-06-11_gotanda.pm

とある企業のPerlモジュール管理の歴史

SUZUKI Masashi

June 11, 2014
Tweet

More Decks by SUZUKI Masashi

Other Decks in Technology

Transcript

  1. とある企業のPerl
    もじゅーる管理
    すずきまさし / @masasuz
    1

    View Slide

  2. おまえだれよ
    すずきまさし / @masasuz
    五反田の辺りにある中小web企業
    6月1日で5年目らしい
    アプリケーションとインフラの中間エン
    ジニア(最近アプリよりに戻された)
    zsh / perl / mysql / Ubuntu / Debian
    2

    View Slide

  3. とある企業のPerl
    もじゅーるかんり
    3

    View Slide

  4. 注意
    3年ちょい前に入社したのでそれ以前の
    ことは歴史書(git)からひもといている
    ので正確で無いです。
    git (+ git-svn)の歴史に刻まれていな
    い、先史時代のことは分かりません。
    4

    View Slide

  5. おおまかな歴史
    先史時代
    丸ごとrsync期
    Debian Package期
    carton期
    5

    View Slide

  6. 先史時代
    知りません
    2006年より前はさかのぼれません
    FreeBSDが使われていたようです
    6

    View Slide

  7. 丸ごとrsync期
    Debian 32bit
    Apache + mod_perl + Sledge
    system perl
    Archer
    7

    View Slide

  8. 丸ごとrsync期 cont..
    CPANプロジェクトをrsync
    バイナリ含む
    8

    View Slide

  9. プロジェクト数が少ない
    全て同じOS/arch
    全サーバで同じモジュールを使える!
    9

    View Slide

  10. 問題
    ディストリビューションのメンテ切れ
    archの差異
    64bit
    バージョン管理が煩雑
    10

    View Slide

  11. Debian Package期
    Debian 32/64bit混在
    Apache + mod_perl + (Sledge or
    Splite)
    cpan-packagerでCPANモジュールをdeb化
    arch / dist 毎に作る
    Archer => Watch2::Deployer
    11

    View Slide

  12. apt-localとapt-proxyサーバ
    xx-cpan-perlというパッケージの依存
    パッケージに全perl deb packageを突っ
    込む
    deploy時にapt-localのインデックス生

    各サーバにssh => aptitude update &&
    aptitude safe-upgrade
    12

    View Slide

  13. 複数 dist/arch混在環境
    バージョン管理ができるように
    全プロジェクト同じモジュール!?
    13

    View Slide

  14. 問題
    カジュアルにパッケージ足しすぎ。カオス
    依存関係地獄
    全プロジェクトに影響
    プロジェクト数が増えてきた
    簡単にバージョン上げられない
    古のモジュールがはびこることに。。
    14

    View Slide

  15. 問題 cont..
    OS自動インストール時に全モジュールを
    インストールしてるのでOSインストール
    に超時間かかる
    全サーバに対してデプロイするので、台
    数に比例してデプロイに時間がかかる
    system のdeb packageとかぶる
    バージョンにepochを付与して回避(ダ
    ウングレード!)
    15

    View Slide

  16. 問題 cont..
    ディストリビューションをアップデー
    トするたびに検証作業が必要。。
    特定のプロジェクトで新しいバージョ
    ンを使うことができない
    プロジェクト同居の可能性があるの
    でextlibに突っ込めない
    16

    View Slide

  17. carton期
    Ubuntu Server 64bit
    carton
    (Upstart +) Server::Starter + Starlet +
    Amon2
    OrePAN2::Server
    not system perl
    独自ビルドしたdeb package
    17

    View Slide

  18. cpanfile(.snapshot)に依存モジュールを記

    carton install —deployment
    プロジェクト毎に独自のモジュールが使える
    社内モジュールはOrePAN2に上げる
    system perlに依存しない
    dist変えやすい
    18

    View Slide

  19. おおまかな歴史
    先史時代
    丸ごとrsync期
    Debian Package期
    carton期 <= イマココ
    19

    View Slide

  20. 正しい歴史
    先史時代
    丸ごとrsync期
    丸ごと(ry + Debian Package期
    丸(ry+Deb(ry or carton期<=イマココ
    20

    View Slide

  21. CPANプロジェクトは最後の最後まで消
    えなかった
    更新が速い(設定系)モジュールが残り
    続けた
    社内モジュール置き場になった。
    21

    View Slide

  22. 新しいプロジェクトじゃないとcarton
    化しにくい
    Apache + mod_perlからの移行が。。
    新規プロジェクトなら楽なので、そ
    こから
    古(いにしえ)のモジュールの関係
    というか実際依存関係ぶっ壊れてる
    22

    View Slide

  23. とはいえ、
    どのスキームも当時のコンテキストに
    はあっていた。
    レガシーなスキームが悪いのでは無く、
    コンテキストが変わってしまったのに、
    レガシーなスキームを使い続けるのが
    悪。
    23

    View Slide

  24. なので、
    すぐには全部変えられないけど、少し
    ずつ、時代に合わないものを消して行っ
    ている途中。
    大事なのは、問題は問題と認識して解
    決の方向に進めること。
    エンジニアだもの文句じゃ無く技術で
    解決しよう。
    24

    View Slide

  25. おしまい
    25

    View Slide