2015-03-25_gotanda.pm4

Transcript

1. 1.

   mod_perl to PSGI/Plack Gotanda.pm #4 LT すずきまさし / @masasuz 2015/03/17

   1
2. 2.

   おまえだれよ すずきまさし / @masasuz 五反田の辺りにある中小web企業 開発/運用基盤的整備 社内システム開発 zsh / perl

   / MySQL / Ubuntu / Debian / i☆Ris 2
3. 3.

   最近使っている ツール/技術/ミドルウェア Elasticsearch + Kibana Fluentd Gitbucket 3

4. 4.

   今年使いたい ツール/技術/ミドルウェア Docker Ansible Sensu 4

5. 5.

   mod_perl to PSGI/Plack Gotanda.pm #4 LT すずきまさし / @masasuz 2015/03/17

   5
6. 6.

   8年近く前から動いているmod_perlなプ ロジェクト群をPSGI/Plack化しようと している。というお話です。 新規で作るプロジェクトはPSGI/Plack で動いてます。 現在進行形です。 6

7. 7.

   もくじ 現状がどうなってるのか どう変えるのか やったこと 発生した問題 7

8. 8.

   新しめの プロジェクト現状 Amon2 Starlet + Server::Starter + Upstart 独自ビルドしたperl(5.18) (Perl::Build)

   cpanfileでのモジュール管理(Carton) 社内モジュールはDarkpanで管理 (OrePAN2::Server) 8
9. 9.

   古めの プロジェクトの現状 Sledge+MoFedge (Splite, Amon2) Apache+mod_perl system perl deb package

   + CPANプロジェクト 9
10. 10.

    古めのプロジェクト 何がつらかったか 10

11. 11.

    sytem perlつらい ディストリビューションが変わる (updateする)とperlのバージョンが変 わる ディストリビューションupdateのた びの検証つらい とはいえ、セキュリティー関連でい つまでも古いディストリビューショ ンを使うわけにはいかない

    11
12. 12.

    Apache+mod_perlつらい プロジェクト同居しているときにプロ ジェクト毎にextlibが設定できない。 同じプロセスのメモリに載ってるた め update . . . .

    . 12
13. 13.

    debian packageつらい 全システム同じバージョンのモジュー ル 新しいモジュール使いにくい バージョン上げにくい 13

14. 14.

    CPANプロジェクト? 14

15. 15.

    CPANプロジェクト? CPANモジュールを雑多に突っ込んだプ ロジェクト バージョン管理? 食べられるの? アーキテクチャ? 美味しいの? パッチ管理? 必要なの? 15

16. 16.

    CPANプロジェクト つらい どのバージョンが入ってるのかよく分 からん x86でビルドされたXS ※現在はない 独自パッチあたってる。けど、どれが あたってるのかよく分からん 16

17. 17.

    つらい 17

18. 18.

    新しめの プロジェクト現状 Amon2 Starlet + Server::Starter + Upstart 独自ビルドしたperl (Perl::Build)

    cpanfileでのモジュール管理(Carton) 社内モジュールはDarkpanで管理 (OrePAN2::Server) 18
19. 19.

    アーキテクチャ変更 Sledge+MoFedge => PSGI対応する Apache+mod_perl => Starlet + Server::Starter +

    Upstart system perl => 独自ビルドしたperl deb package + CPANプロジェクト => carton cpanfile 19
20. 20.

    WAF以外は新しめの プロジェクトと同じ 20

21. 21.

    やらないといけないこと SledgeのPSGI対応 CPANに上がっていないにSledge系のモジュールを Darkpanに登録 CPANに雑多に突っ込まれてるモジュールの分離。 Darkpanへの登録 プロジェクトで使用しているモジュールのバージョン の特定およびcpanfile作成 基本今動いてるのと同じバージョンを使うように プロジェクトコード自体をPSGI対応する

    21
22. 22.

    SledgeのPSGI対応 PSGI対応してあるSledgeに社内の独自 パッチがあたったSledgeをマージ https://github.com/tokuhirom/ Sledge/tree/feature-psgi Sledge::DispatcherもPSGI対応 22

23. 23.

    CPANプロジェクトからの モジュール分離 ディストリビューション名を把握 バージョンを把握 パッチがあたってないかを把握 あたっていればバージョン番号を変 えた上で、Darkpanに登録 23

24. 24.

    プロジェクトで使用している モジュールの特定 dpkg-query —show ‘lib*-perl’の結果 からモジュール名とバージョンを抽出 その結果からmetacpanのElasticsearchに 問い合わせて https://gist.github.com/masasuzu/ b9da1890c51ae2dbc724

    scan-prereqs-cpanfileの結果と照合して あげる 24
25. 25.

    プロジェクトコードの PSGI対応 頼みの綱はテスト %ENVを参照しているところを$req->env から取るように変える。 Apache::Request前提になっている箇所 を変えてあげる 25

26. 26.

    ふー 26

27. 27.

    予想しない問題 古めモジュールがcarton install出来 ない 古めの記法を使っているがゆえの 大量のwarnings よく分からないsyntax error 27

28. 28.

    古めのモジュールが carton installできない cpanfileに指定してるバージョンが見つ からないと言われる 仕方ないのでtarを落としてきてDarkpan に登録する cpanfileでバージョン指定しないとこ の古いバージョンで入るのが罠 現状全てのプロジェクトが同じ

    Darkpanを参照してるので。。。 28
29. 29.

    古い記法 for $hoge qw( ) { } defined @hoge defined

    %hoge 29
30. 30.

    依存モジュール内の 古い記法 パッチを当てて、Darkpanに登録。。。 30

31. 31.

    ふー 31

32. 32.

    古い依存モジュール (細かい系) Jcode Data::Visitor::Encode base これだけはparentに変えた UNIVERSAL::require 32

33. 33.

    まとまらないまとめ Sledge自体のPSGI対応は楽 テストさえ書かれてれば、プロジェクトの対応はそれ ほど難しくない。 まだ本番には投入してない プロジェクトの人のチェック待ち 熟成されたコードをいきなり直すのはだいぶつらいの で、悪い意味で熟成される前に対処した方がよい。 ホントに。。。 33

34. 34.

    ありがとう ございました 34