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
2015-03-25_gotanda.pm4
Search
SUZUKI Masashi
March 25, 2015
Programming
0
1.5k
2015-03-25_gotanda.pm4
mod_perlなプロジェクトをPSGI/Plack対応しようとしてる話。
SUZUKI Masashi
March 25, 2015
Tweet
Share
More Decks by SUZUKI Masashi
See All by SUZUKI Masashi
2025-01-31 吉祥寺.pm 37 初めての海外カンファレンス
masasuzu
0
440
2025-01-24-SRETT11-OpenTofuについてそろそろ調べてみるか
masasuzu
0
330
2024-03-29 SRETT9 Cloud SQLの可用性について
masasuzu
0
420
2023-12-18 SRETT8 Terraform使いがPulumiに入門する
masasuzu
0
2.2k
2023-12-01 吉祥寺.pm ベストプラクティスと組織とIaC
masasuzu
1
1.6k
SRETT#6_Terraformのtfstateについて考える
masasuzu
2
3k
SRETT#4黒い画面をもっと効率的に(使って自動化の時間を捻出)
masasuzu
2
430
2022-04-12 吉祥寺.pm 29
masasuzu
0
1.4k
2015-12-12-chiba.pm7
masasuzu
0
3.4k
Other Decks in Programming
See All in Programming
Formの複雑さに立ち向かう
bmthd
1
940
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
9
2.5k
「個人開発マネタイズ大全」が教えてくれたこと
bani24884
1
250
PRレビューのお供にDanger
stoticdev
1
240
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
260
Learning Kotlin with detekt
inouehi
1
140
読まないコードリーディング術
hisaju
0
110
Jasprが凄い話
hyshu
0
170
はじめての Go * WASM *OCR
sgash708
1
110
SwiftUI Viewの責務分離
elmetal
PRO
2
280
クリーンアーキテクチャから見る依存の向きの大切さ
shimabox
5
1.1k
SwiftUI移行のためのインプレッショントラッキング基盤の構築
kokihirokawa
0
150
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
172
14k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Building an army of robots
kneath
303
45k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
The Language of Interfaces
destraynor
156
24k
Optimizing for Happiness
mojombo
376
70k
What's in a price? How to price your products and services
michaelherold
244
12k
How GitHub (no longer) Works
holman
314
140k
Transcript
mod_perl to PSGI/Plack Gotanda.pm #4 LT すずきまさし / @masasuz 2015/03/17
1
おまえだれよ すずきまさし / @masasuz 五反田の辺りにある中小web企業 開発/運用基盤的整備 社内システム開発 zsh / perl
/ MySQL / Ubuntu / Debian / i☆Ris 2
最近使っている ツール/技術/ミドルウェア Elasticsearch + Kibana Fluentd Gitbucket 3
今年使いたい ツール/技術/ミドルウェア Docker Ansible Sensu 4
mod_perl to PSGI/Plack Gotanda.pm #4 LT すずきまさし / @masasuz 2015/03/17
5
8年近く前から動いているmod_perlなプ ロジェクト群をPSGI/Plack化しようと している。というお話です。 新規で作るプロジェクトはPSGI/Plack で動いてます。 現在進行形です。 6
もくじ 現状がどうなってるのか どう変えるのか やったこと 発生した問題 7
新しめの プロジェクト現状 Amon2 Starlet + Server::Starter + Upstart 独自ビルドしたperl(5.18) (Perl::Build)
cpanfileでのモジュール管理(Carton) 社内モジュールはDarkpanで管理 (OrePAN2::Server) 8
古めの プロジェクトの現状 Sledge+MoFedge (Splite, Amon2) Apache+mod_perl system perl deb package
+ CPANプロジェクト 9
古めのプロジェクト 何がつらかったか 10
sytem perlつらい ディストリビューションが変わる (updateする)とperlのバージョンが変 わる ディストリビューションupdateのた びの検証つらい とはいえ、セキュリティー関連でい つまでも古いディストリビューショ ンを使うわけにはいかない
11
Apache+mod_perlつらい プロジェクト同居しているときにプロ ジェクト毎にextlibが設定できない。 同じプロセスのメモリに載ってるた め update . . . .
. 12
debian packageつらい 全システム同じバージョンのモジュー ル 新しいモジュール使いにくい バージョン上げにくい 13
CPANプロジェクト? 14
CPANプロジェクト? CPANモジュールを雑多に突っ込んだプ ロジェクト バージョン管理? 食べられるの? アーキテクチャ? 美味しいの? パッチ管理? 必要なの? 15
CPANプロジェクト つらい どのバージョンが入ってるのかよく分 からん x86でビルドされたXS ※現在はない 独自パッチあたってる。けど、どれが あたってるのかよく分からん 16
つらい 17
新しめの プロジェクト現状 Amon2 Starlet + Server::Starter + Upstart 独自ビルドしたperl (Perl::Build)
cpanfileでのモジュール管理(Carton) 社内モジュールはDarkpanで管理 (OrePAN2::Server) 18
アーキテクチャ変更 Sledge+MoFedge => PSGI対応する Apache+mod_perl => Starlet + Server::Starter +
Upstart system perl => 独自ビルドしたperl deb package + CPANプロジェクト => carton cpanfile 19
WAF以外は新しめの プロジェクトと同じ 20
やらないといけないこと SledgeのPSGI対応 CPANに上がっていないにSledge系のモジュールを Darkpanに登録 CPANに雑多に突っ込まれてるモジュールの分離。 Darkpanへの登録 プロジェクトで使用しているモジュールのバージョン の特定およびcpanfile作成 基本今動いてるのと同じバージョンを使うように プロジェクトコード自体をPSGI対応する
21
SledgeのPSGI対応 PSGI対応してあるSledgeに社内の独自 パッチがあたったSledgeをマージ https://github.com/tokuhirom/ Sledge/tree/feature-psgi Sledge::DispatcherもPSGI対応 22
CPANプロジェクトからの モジュール分離 ディストリビューション名を把握 バージョンを把握 パッチがあたってないかを把握 あたっていればバージョン番号を変 えた上で、Darkpanに登録 23
プロジェクトで使用している モジュールの特定 dpkg-query —show ‘lib*-perl’の結果 からモジュール名とバージョンを抽出 その結果からmetacpanのElasticsearchに 問い合わせて https://gist.github.com/masasuzu/ b9da1890c51ae2dbc724
scan-prereqs-cpanfileの結果と照合して あげる 24
プロジェクトコードの PSGI対応 頼みの綱はテスト %ENVを参照しているところを$req->env から取るように変える。 Apache::Request前提になっている箇所 を変えてあげる 25
ふー 26
予想しない問題 古めモジュールがcarton install出来 ない 古めの記法を使っているがゆえの 大量のwarnings よく分からないsyntax error 27
古めのモジュールが carton installできない cpanfileに指定してるバージョンが見つ からないと言われる 仕方ないのでtarを落としてきてDarkpan に登録する cpanfileでバージョン指定しないとこ の古いバージョンで入るのが罠 現状全てのプロジェクトが同じ
Darkpanを参照してるので。。。 28
古い記法 for $hoge qw( ) { } defined @hoge defined
%hoge 29
依存モジュール内の 古い記法 パッチを当てて、Darkpanに登録。。。 30
ふー 31
古い依存モジュール (細かい系) Jcode Data::Visitor::Encode base これだけはparentに変えた UNIVERSAL::require 32
まとまらないまとめ Sledge自体のPSGI対応は楽 テストさえ書かれてれば、プロジェクトの対応はそれ ほど難しくない。 まだ本番には投入してない プロジェクトの人のチェック待ち 熟成されたコードをいきなり直すのはだいぶつらいの で、悪い意味で熟成される前に対処した方がよい。 ホントに。。。 33
ありがとう ございました 34