2014-06-11_gotanda.pm

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

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

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

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

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

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

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

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

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

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

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

apt-localとapt-proxyサーバ xx-cpan-perlというパッケージの依存パッケージに全perl deb packageを突っ込む deploy時にapt-localのインデックス生成各サーバにssh =>
aptitude update && aptitude safe-upgrade 12

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

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

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

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

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

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

2014-06-11_gotanda.pm

2014-06-11_gotanda.pm

SUZUKI Masashi

More Decks by SUZUKI Masashi

Other Decks in Technology

Featured

Transcript

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

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

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

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

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

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

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

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

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

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

Debian Package期 Debian 32/64bit混在 Apache + mod_perl + (Sledge or

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

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

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

問題 cont.. OS自動インストール時に全モジュールをインストールしてるのでOSインストールに超時間かかる全サーバに対してデプロイするので、台数に比例してデプロイに時間がかかる system のdeb packageとかぶる

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

carton期 Ubuntu Server 64bit carton (Upstart +) Server::Starter + Starlet

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

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

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

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

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

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

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

おしまい 25