たった一ファイルの python スクリプトから始めるOSS開発入門 / PyCon JP 2016

たった一ファイルの python スクリプトから始めるOSS開発入門 / PyCon JP 2016

1. 1. たった一ファイルの python スクリプトから始める OSS 開発入門 PyCon JP 2016 2016‒09‒21 Wed GMO Pepabo, Inc Kei IWASAKI
2. 2. お前誰？
3. 3. Kei IWASAKI Twitter: @laugh̲k Github: @laughk GMOペパボ ‒ 技術部所属 最近は tetote というサービスの開発などの技術支援を行う ペパボでは珍しく python & Django を触っている 元MSPのWeb系インフラエンジニア ペパボでも元々はインフラエンジニア
4. 4. https://tetote‒market.jp
5. 5. #pyhack
6. 6. 今日のお話
7. 7. プログラムコードを書かないWeb系インフラエン ジニアが python を通じてコードを書くようにな り、その成果物をオープンにするようになった体 験とその時の起こった技術的な広がりの話 ※ 突っ込んだ技術的な話はありません
8. 8. 対象 普段コードを書きたいと思ってもなかなかかけていない人 将来的にもっとコードを書くことを自分の業務の中心にしていきたいと考え ている人 身近なスクリプトを公開していくことに興味がある人 特にWeb系インフラエンジニアの方
9. 9. Outline 1. 簡単な監視やオペレーションの自動化をはじめていたころの話 2. コマンドラインツールの開発に乗り出して行った話 3. github/PyPI に成果物をのせてみた話 4. オープンにすることも自然になっていった話 5. おわりに
10. 10. 1. 簡単な監視やオペレーションの自 動化をはじめていたころ
11. 11. もちろん最初から手を動かして コードの力を活用できていたわけではない
12. 12. 数年前のお仕事 サーバのお世話 サーバの初期構築 SSH経由のコマンドラインに寄るオペレーション 機器の購入や遊休化などの資産管理的なこと データセンタでラッキング、ケーブリング 障害対応 ドキュメント 手順書(ここでこのコマンドを実行するなどをまとめたもの) Excel/Word メールチェック 送信元はだいたい人間じゃない などなど
13. 13. 普通に過ごしていると プログラムはほぼ触らない
14. 14. 慣れてくればオペレーションのスキルもそこそこ上がる し、ドキュメントの書き方もわかってくる。でも日々の業 務の延長線上だけで過ごしてといずれ技術者としてできる ことが頭打ちになってくる という危機感が日に日に強くなっていた
15. 15. たしかに、サーバー構築自体は効率よくできるようになっているでもそれはエン ジニアとして成長しているわけではなく、ただサーバーをつくるのがうまくなっ ているだけなんです 【後編】第5回ペパボテックカンファレンス～インフラエンジニア大特集～開 催レポート より
16. 16. 手を動かさなきゃ！！！
17. 17. 少しずつ手をつけていった シェル芸も磨いてそもそものオペレーションスキルを上げた 何度も同じことをすることはスクリプト化 Perl も試してみた Python も触ってみた
18. 18. Python に馴染めた 書き方が矯正される分、時間を開けながら見てもそこまで苦労せずに読み書 きできた 雰囲気がシェルスクリプトと違って戸惑ったけど、それは最初だけだった Linuxサーバであればどこでも使えるのも大きかった デプロイツールとして有名な fabric も使いやすかった
19. 19. この時意識していたこと 無理矢理にでもコードを書く方向に仕事をもっていった 時間に余裕があるときは「これコード書いて楽できないか？」を考えて強引 にでも手を動かす 既に配置されてる監視スクリプトなど既存のコマンドの中身を覗いてみて参 考にしたりもした 緊急時やそれっきりではないとき「それシェル芸でいいじゃん」という気持 ちをこらえる
20. 20. 少しずつ身についていった そこそこ複雑な作業であったり、シェルスクリプトがつらくなってきたら Python を使うようになっていった 標準ライブラリの使い方も覚えていき、徐々に手に馴染むようになってきた
21. 21. Python を使い始めて幅が広がった例
22. 22. fabric による複数サーバに対するオ ペレーションの自動化 メンバーの増減に伴うあたたかみのある usradd (userdel) x 稼働サーバか らの開放など
23. 23. fabric による複数サーバに対するオ ペレーションの自動化 fabfile.py: from fabric.api import sudo def useradd(): sudo('useradd -m -d /home/laughk laughk') ユーザー追加 $ fab -H hostname1,hostname2,... useradd
24. 24. 複雑な状況のAkamaiのキャッシュパ ージ Akamai の複雑な条件でのキャッシュパージ PyPI に ccuapi というキャッシュ関連のAPIを扱うライブラリがある 実際にあったケースは http://<ドメイン名>/<アカウントID1>/<アカウントID2>/etc/...
25. 25. シェルコマンドだけでは困難な調査 URLエンコードをした状態のファイルパスで 255byte を超えるもの一覧を取得する 対象のファイル名一覧は find コマンド + fabric でリストファイルとして取得 リストファイルのファイルパスを URL encode した状態ですべて評価 python スクリプトは urllib, re, sets の標準モジュールだけで可能だった
26. 26. バク速になった例 シェルスクリプトよりもパフォーマンスの面でよかった例 find + xargs によるリネームよりも os/glob モジュールを使った python ス クリプトのリネームのほうが早かった
27. 27. 少しずつにできることが増え 技術的な広がりを感じ始めた
28. 28. とはいえ広がりの限界もあった
29. 29. 書いたスクリプトは実行したサーバにそのまま放置されてしまい、結果自分 でも存在を忘れがち 過去の成果物をよその環境で使いたいと思ったときに移植するのが非常に面 倒だったりする バージョン管理、構成管理がされないケースのほうが多い結果として秘伝の タレの一部と化すこともある
30. 30. 場当たり的なスクリプトの限界を感 じ始めた
31. 31. ここまでまとめ
32. 32. ここまでまとめ  業務だけで得られる知識だけでは技術的に取り残されそうという危機感から 手を動かし始めた 業務にも使えそうなものを色々試してみて python が一番手に馴染んだ 無理矢理でも業務で使い、少しずつできることが増え、技術的な広がりを実 感してきた とはいえ場当たり的にコードを書いてるだけでは問題も出てきた
33. 33. 2. コマンドラインツールの開発に乗 り出して行った話
34. 34. 状況に応じて機会を見つけてコードを書いた りしてみるもののどこか「裏技」のような感 覚が抜けきれないでいた
35. 35. 転機
36. 36. 「fabric 便利だけどもう少しワンラ イナーで気軽に使いたいねー」
37. 37. 「fabric 便利だけどもう少しワンライナーで気軽 に使いたいねー」という声を聞く ※ 便利なので個人のオペレーション効率化でよく使っていた
38. 38. 「fabric.api.execute 使えば wrapper みたいなの 作れるのでは」と思い始める
39. 39. ということで作った
40. 40. cmspkit
41. 41. cmspkit カラーミショップのインフラチームに在籍中に制作 cmsp(カラーミーショップ) + kit(道具) 日々の運用を便利にすることを目標に作ったもの 主に role ごとのリモートコマンドをいい感じに実行してくれる カラーミーショップのインフラ環境に特化したものなので非公開
42. 42. cmspkit 使っている技術の詳細についてはこちら http://www.slideshare.net/laughk/3‒53764813
43. 43. cmspkit # リモートにてコマンド実行 $ cmspkit remote exec [options] # リモートのファイル取得 $ cmspkit remote get [options] # リモートにファイルを転送 $ cmspkit remote push [options] 主なオプション -s, --sudo ... sudo を利用して root 実行をする -H, --hostname ... 実行対象をIPやホスト名指定`,`区切りで複数化 -R, --roles ... 実行対象をロール名で指定する `,` 区切りで複数化 -P, --parallel ... パラレルで実行数も指定可能 -c, --command ... exec 用オプション 実行するシェルコマンド指定する
44. 44. cmspkit 例 構成管理するまでもないスクリプトファイルの配布 img ロールに配布する場合 $ cmspkit remote push > -s -P 3 --roles img > -f send-to-bayt/rsync-to-bayt.sh > -d /root/send-to-bayt/rsync-to-bayt.sh [img20a.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync [img17.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync- [img13.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync- [img08.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync- [img06.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync- [img04.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync- [img03.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync- [img02.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync- [img.***.jp] put: send-to-bayt/rsync-to-bayt.sh -> /root/send-to-bayt/rsync-
45. 45. cmspkit 例 img ロールで home の残り容量がヤバイ順に sort [laughk@manage00i ~]$ cmspkit remote exec -R img -c 'df -h /home' | grep [img01.***.jp] Login password for 'laughk': [img12.***.jp] out: 168G 155G 13G 93% /home [img05.***.jp] out: 487G 469G 19G 97% /home [img10.***.jp] out: 168G 143G 26G 85% /home [img07.***.jp] out: 488G 459G 30G 94% /home [img16.***.jp] out: 168G 125G 34G 79% /home [img14.***.jp] out: 488G 452G 37G 93% /home [img11.***.jp] out: 488G 425G 39G 92% /home [img15.***.jp] out: 481G 442G 40G 92% /home [img09.***.jp] out: 168G 112G 48G 71% /home [img17.***.jp] out: 488G 437G 52G 90% /home [img04.***.jp] out: 168G 104G 56G 65% /home [img13.***.jp] out: 488G 406G 59G 88% /home [img06.***.jp] out: 488G 401G 63G 87% /home [img08.***.jp] out: 481G 418G 63G 88% /home [img02.***.jp] out: 488G 424G 65G 87% /home
46. 46. cmspkit この時に気を使ったこと 配布しやすいようにパッケージング 共通踏み台サーバにはインストール 「ツール作ったよー」ということを宣伝
47. 47. cmspkit 配布しやすいようにパッケージング pip install で入れれるようにする作業 setup.py を含んだリポジトリを Github Enterprise においた やり方は Python プロフェッショナルプログラミング 第2版 の Part1 Chapter3 の 「Pythonプロジェクト の構成とパッケージ作成」の情報をもとに 今だと @tell‒k さんの PyPIデビュー 2015 がものす ごく参考になる
48. 48. cmspkit 共通踏み台サーバにはインストール 他のチームメンバーが必ずログインする場所にセットアップすることですぐ 試せるように パッケージングのおかげで以下の通りでOK $ pip install > git+https://ghe-url.example.com/cmspkit/cmspkit.git
49. 49. cmspkit 「ツール作ったよー」ということも宣伝
50. 50. cmspkit 「ツール作ったよー」ということを宣伝 フィードバックももらえたりした
51. 51. このとき得たもの
52. 52. このとき得られたもの パッケージングのノウハウ Github Enterprise 上で管理これまで煩雑になっていたツールの管理が一元化 された 各環境への配布が非常に楽になった ヘルプやREADMEなど使ってもらうことも意識するようになった
53. 53. なによりも
54. 54. 一つのプロダクトとして提供することでノウハウ を確実に簡単に広められ、フィードバックもすぐ に反映できた
55. 55. ここまでまとめ
56. 56. ここまでまとめ  場当たり的にスクリプトを書いているうちはどこか「裏技」のような感覚が あった 使ってもらえるツールとして作りきってみるとプロダクトとして自分以外の 人にも認識され、確実なノウハウ展開とフィードバック反映ができるように なった 使ってもらうツールとして作るにはインストール方法や使い方など、単純な 機能以外も気にすることが多かった
57. 57. 3. Github / PyPI に成果物をのせて みた
58. 58. takosan というものがある https://github.com/kentaro/takosan 単純な HTTP POST で Slack に通知できる Web インターフェースペパボ社内 では頻繁に使われてる sample: takosan を起動しているサーバへポストする $ curl > -d 'channel=@laughk' > -d 'message=Hello PyConJP 2016' > http://takosan.example.com:4979/notice
59. 59. この takosan のクライアントをつく ってみた
60. 60. kite‒string
61. 61. kite‒string https://github.com/laughk/kite‒string sample: $ kite > --channel '@laughk' > --message 'Hello PyCon JP 2016' > http://takosan.example.com:4979/notice タコ糸 curl で 「-d 'key=value'」 といちいち書くのが面臭くなったのでワンラ イナーで使えるコマンドツールとして作ってみた 技術的には CLI フレームワーク Click と requests を使用 元々は cmspkit 同様社内向けにして公開するつもりもなかった
62. 62. これ、公開してもいいのでは？
63. 63. 勢いでPyPIへ登録 takosan がオープンなものなのでいいやという軽い気持ちで PyPI に登録 アップロード方法はググると結構古い情報が引っかかってしまったけど、プ ロフェッショナルPythonプログラミング第2版が参考に 今だと PyPIデビュー 2015 一番良くまとまっている
64. 64. 公開したときの気持ち https://memo.laughk.org/2015/06/07/kite‒string‒release.html
65. 65. 公開したときの気持ち 勢いで一つの目標を達成してしまった
66. 66. ここでまとめ
67. 67. ここでまとめ  自分で作ったものが単純な pip install で導入できてテンションあがったそし て本当に便利 これをきっかけに他の PyPI に乗っかっているコードをより身近なものと感 じるようになった 同時にオープンにすることに対する自分の中の敷居が一気に下がった
68. 68. ツール自体は大して流行ったとかはは無いけ れど、公開するという体験が精神的な障壁を 取り除いた
69. 69. 完璧ではなかったものの 自分の中でのブレイクスルーを感じ た
70. 70. 4. オープンにすることが自然になっ ていった話
71. 71. 監視周りをどうにかしたいという状 況になった クラウド環境のため新規で Nagios/Munin を入れるのはなかなかつらそうだ った かといって Mackerel のような外部サービスは予算的に厳しい 一般的には自動化周りのノウハウが枯れている Zabbix がよさそう！となっ た
72. 72. オープンに検証 https://github.com/laughk/zabbix‒playbook‒ubuntu Ansible Plyabook を公開した状態でつくり DigitalOcean でひたすら検証 role として使うことを前提に書いたので、「イケるな！」となったらそのま まプロダクション環境へ適応できた
73. 73. アラート通知が課題に やりたかったのはSlack通知 Zabbix側でもSlack側でも特に標準で用意はされていなかった いくつか公開されているスクリプトもあったけど「コピペして適宜編集よろ しく！」というスタイル 管理が煩雑になりそうで運用上あまり使いたくない
74. 74. ということで作った
75. 75. zbx2slack
76. 76. zbx2slack   https://pypi.python.org/pypi/zbx2slack 実はたった1ファイルの Python スクリプト コマンドのオプションに通知したい情報を渡せばすべてが完結するもの 最初から「公開して配布できるようにすることを前提」に書いた
77. 77. zbx2slack を作るとき意識したこと 使うことだけに集中してもらいたかった 利用者は中身をいじらなくてもいい 通知に必要な情報は全部コマンドオプションで渡せる 配布を極力簡単にするために1ファイルにすべてまとめた pip install するもよし、直接 wget してサーバにおくもよし CentOS 6 (python2.6) も条件付きで考慮
78. 78. この体験で得た気づき
79. 79. この体験で得た気づき 何らかのOSSソフトフェアを選定するときは、覗けるならばコードも読みつ つ更新状況やGithubのIssueなど生きているのかを気にするようになった オープンにすることが前提になることによって自分の環境特有のハードコー ディングがなくなり、解決したい問題をより一般的に捉えるようになった 「これ公開しちゃまずそう」と思うことでも「一般的なこういうことをする 技術」というところをきちんと切り出すことができれば案外自由にできる 1ファイルのスクリプトも、「こういう問題を解決する」「こういうことが できるようになる」ということが満たせているのであれば十二分に公開する 価値はある OSSとして、自分のものとして取り組めるので好きな技術で開発できる
80. 80. ここまでをまとめると
81. 81. ここまでをまとめると たった一つのスクリプトを書き捨てる程度から、Python を好きになりここま でやってくる事ができた 確実にコードの力で何かを解決する力が身についてきている オープンにすることによって技術的な視野の広がりも体験して、Pythonにと どまらないものになってきている
82. 82. おまけ
83. 83. Python に限らず色々オープンにする ようになった例
84. 84. 自分のブログのテーマ https://github.com/laughk/pelican‒ hss 静的サイトジェネレータ Pelican の テーマ シングルページレイアウトで個人的 に気に入るものがなかったので、フ ォークしてカスタムしたもの
85. 85. Django チュートリアルをオープンに すすめてみる https://github.com/laughk/py3‒ django‒tutorial 取り組んだ日付ごとにPRで管理 後で自分で振り返ってみるのに便利 だったりする
86. 86. PCセットアップの記録 https://github.com/laughk/dell‒ xps15‒9550 ブログとは違う粒度でログとして残 しつつアウトプットする場として Issue だけ使ってる
87. 87. おわりに
88. 88. ささいなスクリプトでも使われることを意識して 公開していけば目の前の問題は明確になり、他の 誰かの問題も解決できるかもしれない
89. 89. 誰かの作ったスクリプトも 目的を理解して今まで以上に使いこなせるように なって、そんな行動がきっと自身の可能性を広げ て行いきます
90. 90. たった一ファイルの python スクリプトから始める OSS開発 一緒にやっていきませんか？