Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

"Continuous Publication" with Python: Another Approach

3,265 views

Published on

Presentation slide for #pyconjp2014

Published in: Software
  • Be the first to comment

"Continuous Publication" with Python: Another Approach

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

×