Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2014-06-11_gotanda.pm
Search
SUZUKI Masashi
June 11, 2014
Technology
1
2.1k
2014-06-11_gotanda.pm
とある企業のPerlモジュール管理の歴史
SUZUKI Masashi
June 11, 2014
Tweet
Share
More Decks by SUZUKI Masashi
See All by SUZUKI Masashi
2025-06-20 PrivateLinkがNLBなしで作れるようになり便利になった
masasuzu
2
240
2025-01-31 吉祥寺.pm 37 初めての海外カンファレンス
masasuzu
0
510
2025-01-24-SRETT11-OpenTofuについてそろそろ調べてみるか
masasuzu
0
1.1k
2024-03-29 SRETT9 Cloud SQLの可用性について
masasuzu
0
480
2023-12-18 SRETT8 Terraform使いがPulumiに入門する
masasuzu
0
2.4k
2023-12-01 吉祥寺.pm ベストプラクティスと組織とIaC
masasuzu
1
1.6k
SRETT#6_Terraformのtfstateについて考える
masasuzu
2
3.6k
SRETT#4黒い画面をもっと効率的に(使って自動化の時間を捻出)
masasuzu
2
450
2022-04-12 吉祥寺.pm 29
masasuzu
0
1.5k
Other Decks in Technology
See All in Technology
Amplify Gen2から知るAWS CDK Toolkit Libraryの使い方/How to use the AWS CDK Toolkit Library as known from Amplify Gen2
fossamagna
0
130
開発生産性を測る前にやるべきこと - 組織改善の実践 / Before Measuring Dev Productivity
kaonavi
14
7.9k
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
670
American airlines ®️ USA Contact Numbers: Complete 2025 Support Guide
airhelpsupport
0
390
SREの次のキャリアの道しるべ 〜SREがマネジメントレイヤーに挑戦して、 気づいたこととTips〜
coconala_engineer
1
420
大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化
plaidtech
PRO
0
250
american airlines®️ USA Contact Numbers: Complete 2025 Support Guide
supportflight
1
110
クラウド開発の舞台裏とSRE文化の醸成 / SRE NEXT 2025 Lunch Session
kazeburo
1
400
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
satos
3
1.5k
第64回コンピュータビジョン勉強会「The PanAf-FGBG Dataset: Understanding the Impact of Backgrounds in Wildlife Behaviour Recognition」
x_ttyszk
0
120
〜『世界中の家族のこころのインフラ』を目指して”次の10年”へ〜 SREが導いたグローバルサービスの信頼性向上戦略とその舞台裏 / Towards the Next Decade: Enhancing Global Service Reliability
kohbis
2
840
SREのためのeBPF活用ステップアップガイド
egmc
1
740
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Navigating Team Friction
lara
187
15k
Faster Mobile Websites
deanohume
307
31k
Adopting Sorbet at Scale
ufuk
77
9.5k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
830
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Code Reviewing Like a Champion
maltzj
524
40k
Transcript
とある企業の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