"Continuous Publication" with Python: Another Approach
7 likes4,566 views
Presentation slide for #pyconjp2014
More Related Content
What's hot (18)
Viewers also liked (20)
Similar to "Continuous Publication" with Python: Another Approach (20)
"Continuous Publication" with Python: Another Approach
- 1. "Continuous Publication" with Python: Another Approach This presentation will be in JAPANESE
- 3. 発表者自己紹介 • 宮川大輔 (@amedama) • 株式会社 mokha 取締役 • 「もか」 (もくは) • 前職: Google Inc. (U.S, Android部門)
- 5. 造語
- 7. 「書籍」ビルドシステム Griflet • PDF, epub, InDesign, … • Re:VIEWを採用 • 同人誌～商業書籍の「ビルド」 • 「書籍執筆」を支援
- 8. Re:VIEW • 書籍執筆に強い軽量マークアップ言語 • https://github.com/kmuto/review • @kmuto, @takahashim, @kdmsnr, … • TeX, epub, HTML, InDesign, … • 参考図書: https://github.com/TechBooster/FirstStepReVIEW
- 9. Grifletのきっかけ • 同人誌『Effective Android』 • C84 (2013年 夏コミ) • 著者22人, 184ページ • Re:VIEW + GitHub → すごい！ • だが…… TechBooster代表 @mhidaka
- 10. ビルド失敗に 気づかない
- 11. ビルド失敗に気づかない • 執筆中はビルド結果に無頓着なことが多い • 「HTMLが作れてるのでコミット」 →PDFのビルドが成功するとは限らない • Continuous Integration 環境が( ﾟдﾟ)ﾎｽｨ…
- 12. 自分で作った
- 13. (2) WebHook (1) commit (3) Build Req. (4) Build (6) Download (5) Notify Linux Re:VIEW
- 14. デモ
- 15. ……のサブセット
- 21. 割と手探り • Django, Celery初めて • 「virtualenvって何 (́・ω・｀)」 • 当初、1プロジェクトのみサポート
- 22. 同人誌 → 商業書籍 • 『Effective Android』(TechBooster) = 同人誌 『Effective Android』(達人出版会) = 電子書籍 『Effective Android』(インプレスジャパン) = 紙商業 • 共著者 22人 → 33人 • epub もサポート • Re:VIEW偉大 (＞ヮ＜)
- 23. 次のお題 • TechBooster @ C85 (2013年 冬コミ) • 4冊同時刊行 • 合計1書籍 -> 合計5書籍
- 24. ビルドが たまに止まる orz
- 25. 「たまに止まる」問題 • たまに … 1週間に一回とか • 原因: Celery + GitPythonの組み合わせ • 根本原因は未解明 • 迂回策: subprocess.Popen + git
- 26. Re:VIEWが暴走する
- 27. Re:VIEW暴走事件 • Re:VIEW側のバグ (正規表現が無限ループ化) • Celeryのタイムアウトも効かず……
- 30. C85 も無事に終了
- 31. そこそこ評判が良い
- 32. クチコミヽ(=́▽`=)ﾉ
- 34. ……えっ (ﾟДﾟ)
- 36. is 脅威
- 37. あるいは
- 38. Re:VIEW is 脆弱性
- 39. 「Re:VIEWは脆弱性」問題 • Re:VIEWではRubyコードで命令を拡張出来る • OSコマンドインジェクションそのものじゃね？ • サンドボックスが( ﾟдﾟ)ﾎｽｨ…
- 40. • Immutable Infrastructure • 「軽量VMでOSを囲って実行 -> 廃棄」 • ぴったり(●́ω｀●) • ……と油断していると
- 42. Dockerは不安定？ • あくまで過去形 = 今は比較的安定している • 実際、Dockerのバグには何度か出会った • 自分のミスという部分も多々あった • モニタリング大事
- 43. (2) WebHook (1) commit (3) Build Req. (4) Build (6) Download (5) Notify Linux Re:VIEW
- 44. (2) WebHook (1) commit (3) Build Req. Re:VIEW (4) Build (6) Download (5) Notify Linux
- 45. C86 (2014年 夏) • またもやTechBooster • 他サークルの同人誌も
- 46. 粛々と開発
- 47. 開発上の課題
- 48. 「片手間」開発
- 49. 「片手間」開発 • 長いスパンで少量の実装をちまちま • 一人で「1ヶ月に2～3日。まとめて」
- 50. そして忘れる • 設計・実装・運用の詳細を、忘れる • どのような問題が発生していたかを、忘れる • ユーザフィードバックを、忘れる • 自分が何を達成したいのかまで、忘れる • しばしばここで作るのをやめてしまう
- 51. よくあるよね
- 52. 諦めない(｀･ω･́)
- 53. 対策を考えてみる
- 54. 対策 1
- 55. メモる
- 56. 対策 1: メモる ! • Redmineのチケットに、メモる • ソースコードへのコメントに、メモる
- 59. Redmineのチケット • 作りたい機能、設計上の課題、未解明な点を記録 • 現在: 合計200チケット超 (未完了100超) • 不定期の見直しで「思い出す」
- 60. コードへのコメント • 「理由」「意図」「疑問」をなるべく残す • 含「よく分かってないんだけど何故かこうなる」 • 「何をしているか」のコメントは避ける • 整合性がとれなくなると余計に混乱する
- 61. 対策 2
- 62. ログる
- 63. 対策 2: ログる • = ログに残す • 「ここ通ったら、あかーん」というログも • コメントの代わりにログにしてしまう • RotatingFileHandlerでサイズを抑える • 注: サービス規模が大きくなったらもちろん無理
- 64. それでも見失う • print() になってる • logging.debug() って書いてる
- 65. Loggerを活用する • print()を避ける • “logging”自体 インポートしない • 関数の仮引数にlogger • http://qiita.com/amedama/items/ b856b2f30c2f38665701 from logging import getLogger, DEBUG from logging import NullHandler local_logger = getLogger(__name__) handler = NullHandler() handler.setLevel(DEBUG) local_logger.setLevel(DEBUG) local_logger.addHandler(handler) ! def some_func(…, logger=None): logger = logger or local_logger logger.error(u“some_func() なう”)
- 66. 「開発ログ」と「運用ログ」 • Logging Context が与えられない • 1つの関数で2つのloggerを管理したくはない
- 67. テスト……？
- 68. ユニットテスト • モックアウトが「無駄」になりやすい • 「外部ツールのリアルな挙動」が問題の発生源 • Viewについて重点的に
- 69. 回帰テスト/結合テスト • 外部の世界: Docker, Re:VIEW, …… • 片手間の最中に「変わってしまう」ことがある • 効率的にこの変化を捉える(́・ω・｀)
- 70. Python処理系も外部に？ • 例: Python 2 v.s. Python 3
- 71. Linux Re:VIEW Re:VIEW Re:VIEW Python 2.7 Python 3.4 Python 3.5 (願望です)
- 72. 今後について
- 73. 今後のGriflet • 未だ「粛々と開発」 • 「一般公開」出来る水準にしたい • 一部オープンソース化 • https://github.com/dmiyakawa/pyrev • Re:VIEWのメタデータ解析 + Lintチェッカ
- 75. This page is intentionally left blank
- 76. ……
- 78. 「片手間」開発 ≒ 趣味
- 79. 問題を愉しむ
- 80. 運用環境の裏でテストしたい • 新しい原稿データでその場で「A/B テスト」 • ここはあくまで今後の「希望」
- 81. Re:VIEW Linux
- 84. Linux Re:VIEW Re:VIEW Re:VIEW
- 85. Linux Re:VIEW Re:VIEW Re:VIEW Python 2.7 Python 3.4 Python 3.5
- 86. Linux Re:VIEW Re:VIEW Re:VIEW Python 2.7 Python 3.4 Python 3.5
- 87. あくまでアイディア
- 88. 楽か？(́・ω・｀)
- 89. バージョン管理の苦悩 • 分離した部分でのセキュリティは自分で責任を持つ • 他人 (OSディストリビューション等) に どこまで頼って、どこから自分でやるのか？ • 全環境を expose するわけではないので…… • ただ、考えておく必要はある
- 90. 新しい何か ≒ 新しい問題 ≒新しい発見 • 「検証 ~= 実装」 • 公開サービスではないので落ちてても切れる赤の 他人がいない (今回助かるポイント) • 簡単な部分で敢えて一歩踏み出す • 経験値目当て • ただし、ヤバそうな点は忘れないようにメモする
- 91. ライブラリなのか それより下なのか • 多様な条件を切り替えられると気分が楽 • CentOSに乗っける？問題ないだろ(｀･ω･́) • ……systemdコワイ(́・ω・｀) • OS固有の問題、Python環境の問題、ライブラリの 問題、外部サービスの問題 • 切り分けられるポイントで切り替える練習
- 92. 実際、環境の一本化に やや難を感じている • 個人の事情もあるものの • 開発マシン: Debian 7 (wheezy) • 個人サーバ: Debian 7 (wheezy) • テスト環境: Ubuntu 12.04 LTS / Ubuntu 14.04 LTS • 「これも経験」と割り切る • (仕事の運用環境は一本化するのがベター) • BSDマダー
- 93. 違うLinux 細かいところでズレる ! • Ubuntu 12.04 -> django 1.3 • 使っていた reverse_lazy() がない • Pythonから上のレベルではせめて統一……
- 94. 分離
- 95. virtualenv / venv • Python実行環境分離 • 実行環境を(言語バージョン同じで)もう一つ作る • PyPiのパッケージも別管理 • 最近 (3.3以降) なら(py)venv • 以降 venv = virtualenv or pyvenv • ……というか、どう呼ぶのがベストなの？
- 96. Django + venv の苦悩 • activate忘れ (Apache, Celery含めて) • しかもある程度動作してしまうこともある…… • OS本体側にsudo pip全くしないのはどう？ • あるいはmanage.pyの段階で強制？
- 97. Python環境も 選びたくなる
- 98. Python環境も選びたい • virtualenvはPythonバージョン固定 • make install すればいいのだが • 何かラフにでいいから管理したい
- 99. pyenv + venv • pyenv で任意のPython実行環境を(ユーザレベルで)用意 • virtualenvのPython実行環境まるごと版みたいなの • https://github.com/yyuu/pyenv • rbenvのPython版なのでpyenv • 注意: pyenv ≠ pyvenv • venvを用いて、プロジェクト固有の環境をもう一つ作る • 3.系のpyvenvでは--copyを付けた方がベター
- 100. pyenv 実用例 • Debian 7 のPython 2.7.3にマイナーなバグが…… • PyPiへのWindowsバイナリがアップ出来ない？ • pyenvで2.7.6を入れることで回避出来た様子 • 言語環境の軽いA/Bテストに使える
- 101. 3種類のPython環境 • システムレベル (OSパッケージ管理) • 保守的、OSに付属する環境が使う • ユーザレベル (pyenv) • 複数のPython環境をユーザが切り替える • OS付属のマイナーバージョンに不満がある場合にも便利 • プロジェクトレベル (pyenv + venv) • プロジェクト毎にPython (+ PyPi) 環境を独立して持つ
- 102. mod_wsgiの苦悩 • venvはApache + mod_wsgi のバージョンを 強制できるわけではない • mod_wsgiのPythonバージョンはOS毎に異なる • 特に2と3の両立は不可 • 他のWSGI依存のプロジェクトに影響する • 安易に変更はできない
- 103. WSGIを境界に
- 104. 今試していること • pyenv + venv + Supervisor + tornado + Apache mod_proxy • どんどん複雑化していておじさん悲しいな
- 105. Supervisor • daemon管理のためのdaemon • Celeryを複数のDjangoプロジェクトで使いたいなら必須 • 後述するtornadoの管理にも使う • OSによっては標準のバージョンが超古くアレなことが？ • Debian 7 -> 2010年の頃のもの • 必要なら sid (unstable) からソースビルド
- 106. tornado • スタンドアローンWeb(WSGI)サーバ • http://www.tornadoweb.org/en/stable/ • Apacheのmod_wsgiを迂回するために使う。 • Django 1.7 + tornadoでの注意 • django.setup() 忘れるなや • 古い「tornado + Djangoを試してみた」系の記事内容だけだとハマる • http://qiita.com/amedama/items/a8f511bd75a14aac0277 • 「異なるバージョンのPython(wsgi)アプリを一つの開発環境上で動かす」
- 107. 素朴な疑問 Supervisor v.s. systemd • 全く分からん(́・ω・｀)
- 108. 気軽に試せる環境が嬉しい • 「Python 3.X + Django 1.Y」をさっくり用意 • /opt 下に一度に飼える • http://qiita.com/amedama/items/a8f511bd75a14aac0277 • http://qiita.com/amedama/items/79994598d9f4daa69d13
- 109. 楽しい!!! ✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌
- 110. ふたたび ありがとうございました
- 111. 想定問答集
- 112. なぜmd/rst/etc.じゃない？ • 極端な話、非常に抽象的なXMLを定義すれば なんでも書ける……はず。 • それをしたくない適切な「軽量マークアップ」は何か • Re:VIEWは複数種類のアウトプット向け • 新しい文法的に拡張をし易い • 文法定義毎に固有の命令を埋め込みやすい • ただし「HTML出たけどPDFとInDesignが死んでる」が起こる • 日本の書籍事情に関与している方々が主導している • 参考: https://github.com/TechBooster/FirstStepReVIEW
- 114. それ使ってみたい • Ask @amedama (Facebook dmiyakawa)
- 115. ☆（ゝω・）vｷｬﾋﾟ