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.3k
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
2024-03-29 SRETT9 Cloud SQLの可用性について
masasuzu
0
210
2023-12-18 SRETT8 Terraform使いがPulumiに入門する
masasuzu
0
1k
2023-12-01 吉祥寺.pm ベストプラクティスと組織とIaC
masasuzu
1
890
SRETT#6_Terraformのtfstateについて考える
masasuzu
2
1k
SRETT#4黒い画面をもっと効率的に(使って自動化の時間を捻出)
masasuzu
2
320
2022-04-12 吉祥寺.pm 29
masasuzu
0
1.3k
2015-12-12-chiba.pm7
masasuzu
0
3.3k
2015-09-17_gotanda.pm6
masasuzu
0
3.4k
2015-07-10-kichijoji.pm4_yurui_template
masasuzu
0
1.2k
Other Decks in Programming
See All in Programming
#phpcon_odawara オープン・クローズドなテストフィクスチャを求めて / open closed test fixtures
77web
3
230
デフォルトにして至高、RubyMineの大好きな所
ruzia
0
270
Changed Rules: Architectures with Lightweight Stores
manfredsteyer
PRO
0
240
Goのエラースタックトレースの歴史と今後
sonatard
7
1.1k
CA.swift19 恋するAIアプリ開発の裏側
oskmr
0
360
PHP8.3の機能を振り返る / Review of PHP 8.3 features
seike460
PRO
1
110
Komplexe Oberflächen mit SVG und der Web Animation API
joergneumann
0
670
try! Swift Tokyo 2024のLT枠に採択されたプロポーザルを出すときに考えていたこと
ski
0
350
OpenAPIを中心に考えるAPI開発入門 / Introduction to API Development with a Focus on OpenAPI
seike460
PRO
2
170
[技育CAMPアカデミア]アイディアを形に!【超入門】スマホアプリ開発〜リリースまでの流れをご紹介
teamlab
PRO
0
360
MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた
ymd65536
1
290
冗長なエラーログを削減し、スタックトレースを手に入れる / Reducing Verbose Error Logs and Obtaining Stack Traces
upamune
0
410
Featured
See All Featured
Done Done
chrislema
178
15k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
25
2.3k
[RailsConf 2023] Rails as a piece of cake
palkan
23
3.9k
YesSQL, Process and Tooling at Scale
rocio
164
13k
We Have a Design System, Now What?
morganepeng
43
6.7k
Automating Front-end Workflow
addyosmani
1356
200k
Making the Leap to Tech Lead
cromwellryan
124
8.5k
The Mythical Team-Month
searls
216
42k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
17
1.4k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
322
20k
Statistics for Hackers
jakevdp
789
220k
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