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
460
2025-01-24-SRETT11-OpenTofuについてそろそろ調べてみるか
masasuzu
0
460
2024-03-29 SRETT9 Cloud SQLの可用性について
masasuzu
0
440
2023-12-18 SRETT8 Terraform使いがPulumiに入門する
masasuzu
0
2.3k
2023-12-01 吉祥寺.pm ベストプラクティスと組織とIaC
masasuzu
1
1.6k
SRETT#6_Terraformのtfstateについて考える
masasuzu
2
3.2k
SRETT#4黒い画面をもっと効率的に(使って自動化の時間を捻出)
masasuzu
2
430
2022-04-12 吉祥寺.pm 29
masasuzu
0
1.4k
2015-12-12-chiba.pm7
masasuzu
0
3.5k
Other Decks in Programming
See All in Programming
The Evolution of Enterprise Java with Jakarta EE 11 and Beyond
ivargrimstad
0
960
自分のために作ったアプリが、グローバルに使われるまで / Indie App Development Lunch LT
pixyzehn
1
120
remix + cloudflare workers (DO) docker上でいい感じに開発する
yoshidatomoaki
0
120
snacks.nvim内のセットアップ不要なプラグインを紹介 / introduce_snacks_nvim
uhooi
0
350
データベースエンジニアの仕事を楽にする。PgAssistantの紹介
nnaka2992
9
4.2k
AHC 044 混合整数計画ソルバー解法
kiri8128
0
300
Firebase Dynamic Linksの代替手段を自作する / Create your own Firebase Dynamic Links alternative
kubode
0
180
私の愛したLaravel 〜レールを超えたその先へ〜
kentaroutakeda
12
3.6k
令和トラベルにおけるコンテンツ生成AIアプリケーション開発の実践
ippo012
1
260
AtCoder Heuristic First-step Vol.1 講義スライド(山登り法・焼きなまし法編)
takumi152
3
980
生成AIの使いどころ
kanayannet
0
100
PHPによる"非"構造化プログラミング入門 -本当に熱いスパゲティコードを求めて- #phperkaigi
o0h
PRO
0
1.1k
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
Navigating Team Friction
lara
184
15k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.6k
Optimizing for Happiness
mojombo
377
70k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.6k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
470
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
118
51k
The World Runs on Bad Software
bkeepers
PRO
67
11k
GraphQLの誤解/rethinking-graphql
sonatard
70
10k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
GraphQLとの向き合い方2022年版
quramy
45
14k
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