1. たった一ファイルの
python スクリプトから始める
OSS 開発入門
PyCon JP 2016
2016‒09‒21 Wed
GMO Pepabo, Inc
Kei IWASAKI

2. お前誰？

3. Kei IWASAKI
Twitter: @laugh̲k
Github: @laughk
GMOペパボ ‒ 技術部所属
最近は tetote というサービスの開発などの技術支援を行う
ペパボでは珍しく python & Django を触っている
元MSPのWeb系インフラエンジニア
ペパボでも元々はインフラエンジニア

4. https://tetote‒market.jp

5. #pyhack

6. 今日のお話

7. プログラムコードを書かないWeb系インフラエン
ジニアが python を通じてコードを書くようにな
り、その成果物をオープンにするようになった体
験とその時の起こった技術的な広がりの話
※ 突っ込んだ技術的な話はありません

8. 対象
普段コードを書きたいと思ってもなかなかかけていない人
将来的にもっとコードを書くことを自分の業務の中心にしていきたいと考え
ている人
身近なスクリプトを公開していくことに興味がある人
特にWeb系インフラエンジニアの方

9. Outline
1. 簡単な監視やオペレーションの自動化をはじめていたころの話
2. コマンドラインツールの開発に乗り出して行った話
3. github/PyPI に成果物をのせてみた話
4. オープンにすることも自然になっていった話
5. おわりに

10. 1. 簡単な監視やオペレーションの自
動化をはじめていたころ

11. もちろん最初から手を動かして
コードの力を活用できていたわけではない

12. 数年前のお仕事
サーバのお世話
サーバの初期構築
SSH経由のコマンドラインに寄るオペレーション
機器の購入や遊休化などの資産管理的なこと
データセンタでラッキング、ケーブリング
障害対応
ドキュメント
手順書(ここでこのコマンドを実行するなどをまとめたもの)
Excel/Word
メールチェック
送信元はだいたい人間じゃない
などなど

13. 普通に過ごしていると
プログラムはほぼ触らない

14. 慣れてくればオペレーションのスキルもそこそこ上がる
し、ドキュメントの書き方もわかってくる。でも日々の業
務の延長線上だけで過ごしてといずれ技術者としてできる
ことが頭打ちになってくる
という危機感が日に日に強くなっていた

15. たしかに、サーバー構築自体は効率よくできるようになっているでもそれはエン
ジニアとして成長しているわけではなく、ただサーバーをつくるのがうまくなっ
ているだけなんです
【後編】第5回ペパボテックカンファレンス～インフラエンジニア大特集～開
催レポート より

16. 手を動かさなきゃ！！！

17. 少しずつ手をつけていった
シェル芸も磨いてそもそものオペレーションスキルを上げた
何度も同じことをすることはスクリプト化
Perl も試してみた
Python も触ってみた

18. Python に馴染めた
書き方が矯正される分、時間を開けながら見てもそこまで苦労せずに読み書
きできた
雰囲気がシェルスクリプトと違って戸惑ったけど、それは最初だけだった
Linuxサーバであればどこでも使えるのも大きかった
デプロイツールとして有名な fabric も使いやすかった

19. この時意識していたこと
無理矢理にでもコードを書く方向に仕事をもっていった
時間に余裕があるときは「これコード書いて楽できないか？」を考えて強引
にでも手を動かす
既に配置されてる監視スクリプトなど既存のコマンドの中身を覗いてみて参
考にしたりもした
緊急時やそれっきりではないとき「それシェル芸でいいじゃん」という気持
ちをこらえる

20. 少しずつ身についていった
そこそこ複雑な作業であったり、シェルスクリプトがつらくなってきたら
Python を使うようになっていった
標準ライブラリの使い方も覚えていき、徐々に手に馴染むようになってきた

21. Python を使い始めて幅が広がった例

22. fabric による複数サーバに対するオ
ペレーションの自動化
メンバーの増減に伴うあたたかみのある usradd (userdel) x 稼働サーバか
らの開放など

23. fabric による複数サーバに対するオ
ペレーションの自動化
fabfile.py:
from fabric.api import sudo
def useradd():
sudo('useradd -m -d /home/laughk laughk')
ユーザー追加
$ fab -H hostname1,hostname2,... useradd

24. 複雑な状況のAkamaiのキャッシュパ
ージ
Akamai の複雑な条件でのキャッシュパージ
PyPI に ccuapi というキャッシュ関連のAPIを扱うライブラリがある
実際にあったケースは
http://<ドメイン名>/<アカウントID1>/<アカウントID2>/etc/...

25. シェルコマンドだけでは困難な調査
URLエンコードをした状態のファイルパスで
255byte を超えるもの一覧を取得する
対象のファイル名一覧は find コマンド + fabric でリストファイルとして取得
リストファイルのファイルパスを URL encode した状態ですべて評価
python スクリプトは urllib, re, sets の標準モジュールだけで可能だった

26. バク速になった例
シェルスクリプトよりもパフォーマンスの面でよかった例
find + xargs によるリネームよりも os/glob モジュールを使った python ス
クリプトのリネームのほうが早かった

27. 少しずつにできることが増え
技術的な広がりを感じ始めた

28. とはいえ広がりの限界もあった

29. 書いたスクリプトは実行したサーバにそのまま放置されてしまい、結果自分
でも存在を忘れがち
過去の成果物をよその環境で使いたいと思ったときに移植するのが非常に面
倒だったりする
バージョン管理、構成管理がされないケースのほうが多い結果として秘伝の
タレの一部と化すこともある

30. 場当たり的なスクリプトの限界を感
じ始めた

31. ここまでまとめ

32. ここまでまとめ
業務だけで得られる知識だけでは技術的に取り残されそうという危機感から
手を動かし始めた
業務にも使えそうなものを色々試してみて python が一番手に馴染んだ
無理矢理でも業務で使い、少しずつできることが増え、技術的な広がりを実
感してきた
とはいえ場当たり的にコードを書いてるだけでは問題も出てきた

33. 2. コマンドラインツールの開発に乗
り出して行った話

34. 状況に応じて機会を見つけてコードを書いた
りしてみるもののどこか「裏技」のような感
覚が抜けきれないでいた

35. 転機

36. 「fabric 便利だけどもう少しワンラ
イナーで気軽に使いたいねー」

37. 「fabric 便利だけどもう少しワンライナーで気軽
に使いたいねー」という声を聞く
※ 便利なので個人のオペレーション効率化でよく使っていた

38. 「fabric.api.execute 使えば wrapper みたいなの
作れるのでは」と思い始める

39. ということで作った

40. cmspkit

41. cmspkit
カラーミショップのインフラチームに在籍中に制作
cmsp(カラーミーショップ) + kit(道具)
日々の運用を便利にすることを目標に作ったもの
主に role ごとのリモートコマンドをいい感じに実行してくれる
カラーミーショップのインフラ環境に特化したものなので非公開

42. cmspkit
使っている技術の詳細についてはこちら
http://www.slideshare.net/laughk/3‒53764813

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. 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. 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. cmspkit
この時に気を使ったこと
配布しやすいようにパッケージング
共通踏み台サーバにはインストール
「ツール作ったよー」ということを宣伝

47. cmspkit
配布しやすいようにパッケージング
pip install で入れれるようにする作業
setup.py を含んだリポジトリを Github Enterprise
においた
やり方は Python プロフェッショナルプログラミング
第2版 の Part1 Chapter3 の 「Pythonプロジェクト
の構成とパッケージ作成」の情報をもとに
今だと @tell‒k さんの PyPIデビュー 2015 がものす
ごく参考になる

48. cmspkit
共通踏み台サーバにはインストール
他のチームメンバーが必ずログインする場所にセットアップすることですぐ
試せるように
パッケージングのおかげで以下の通りでOK
$ pip install
> git+https://ghe-url.example.com/cmspkit/cmspkit.git

49. cmspkit
「ツール作ったよー」ということも宣伝

50. cmspkit
「ツール作ったよー」ということを宣伝
フィードバックももらえたりした

51. このとき得たもの

52. このとき得られたもの
パッケージングのノウハウ
Github Enterprise 上で管理これまで煩雑になっていたツールの管理が一元化
された
各環境への配布が非常に楽になった
ヘルプやREADMEなど使ってもらうことも意識するようになった

53. なによりも

54. 一つのプロダクトとして提供することでノウハウ
を確実に簡単に広められ、フィードバックもすぐ
に反映できた

55. ここまでまとめ

56. ここまでまとめ
場当たり的にスクリプトを書いているうちはどこか「裏技」のような感覚が
あった
使ってもらえるツールとして作りきってみるとプロダクトとして自分以外の
人にも認識され、確実なノウハウ展開とフィードバック反映ができるように
なった
使ってもらうツールとして作るにはインストール方法や使い方など、単純な
機能以外も気にすることが多かった

57. 3. Github / PyPI に成果物をのせて
みた

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. この takosan のクライアントをつく
ってみた

60. kite‒string

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. これ、公開してもいいのでは？

63. 勢いでPyPIへ登録
takosan がオープンなものなのでいいやという軽い気持ちで PyPI に登録
アップロード方法はググると結構古い情報が引っかかってしまったけど、プ
ロフェッショナルPythonプログラミング第2版が参考に
今だと PyPIデビュー 2015 一番良くまとまっている

64. 公開したときの気持ち
https://memo.laughk.org/2015/06/07/kite‒string‒release.html

65. 公開したときの気持ち
勢いで一つの目標を達成してしまった

66. ここでまとめ

67. ここでまとめ
自分で作ったものが単純な pip install で導入できてテンションあがったそし
て本当に便利
これをきっかけに他の PyPI に乗っかっているコードをより身近なものと感
じるようになった
同時にオープンにすることに対する自分の中の敷居が一気に下がった

68. ツール自体は大して流行ったとかはは無いけ
れど、公開するという体験が精神的な障壁を
取り除いた

69. 完璧ではなかったものの
自分の中でのブレイクスルーを感じ
た

70. 4. オープンにすることが自然になっ
ていった話

71. 監視周りをどうにかしたいという状
況になった
クラウド環境のため新規で Nagios/Munin を入れるのはなかなかつらそうだ
った
かといって Mackerel のような外部サービスは予算的に厳しい
一般的には自動化周りのノウハウが枯れている Zabbix がよさそう！となっ
た

72. オープンに検証
https://github.com/laughk/zabbix‒playbook‒ubuntu
Ansible Plyabook を公開した状態でつくり DigitalOcean でひたすら検証
role として使うことを前提に書いたので、「イケるな！」となったらそのま
まプロダクション環境へ適応できた

73. アラート通知が課題に
やりたかったのはSlack通知
Zabbix側でもSlack側でも特に標準で用意はされていなかった
いくつか公開されているスクリプトもあったけど「コピペして適宜編集よろ
しく！」というスタイル
管理が煩雑になりそうで運用上あまり使いたくない

74. ということで作った

75. zbx2slack

76. zbx2slack
https://pypi.python.org/pypi/zbx2slack
実はたった1ファイルの Python スクリプト
コマンドのオプションに通知したい情報を渡せばすべてが完結するもの
最初から「公開して配布できるようにすることを前提」に書いた

77. zbx2slack を作るとき意識したこと
使うことだけに集中してもらいたかった
利用者は中身をいじらなくてもいい
通知に必要な情報は全部コマンドオプションで渡せる
配布を極力簡単にするために1ファイルにすべてまとめた
pip install するもよし、直接 wget してサーバにおくもよし
CentOS 6 (python2.6) も条件付きで考慮

78. この体験で得た気づき

79. この体験で得た気づき
何らかのOSSソフトフェアを選定するときは、覗けるならばコードも読みつ
つ更新状況やGithubのIssueなど生きているのかを気にするようになった
オープンにすることが前提になることによって自分の環境特有のハードコー
ディングがなくなり、解決したい問題をより一般的に捉えるようになった
「これ公開しちゃまずそう」と思うことでも「一般的なこういうことをする
技術」というところをきちんと切り出すことができれば案外自由にできる
1ファイルのスクリプトも、「こういう問題を解決する」「こういうことが
できるようになる」ということが満たせているのであれば十二分に公開する
価値はある
OSSとして、自分のものとして取り組めるので好きな技術で開発できる

80. ここまでをまとめると

81. ここまでをまとめると
たった一つのスクリプトを書き捨てる程度から、Python を好きになりここま
でやってくる事ができた
確実にコードの力で何かを解決する力が身についてきている
オープンにすることによって技術的な視野の広がりも体験して、Pythonにと
どまらないものになってきている

82. おまけ

83. Python に限らず色々オープンにする
ようになった例

84. 自分のブログのテーマ
https://github.com/laughk/pelican‒
hss
静的サイトジェネレータ Pelican の
テーマ
シングルページレイアウトで個人的
に気に入るものがなかったので、フ
ォークしてカスタムしたもの

85. Django チュートリアルをオープンに
すすめてみる
https://github.com/laughk/py3‒
django‒tutorial
取り組んだ日付ごとにPRで管理
後で自分で振り返ってみるのに便利
だったりする

86. PCセットアップの記録
https://github.com/laughk/dell‒
xps15‒9550
ブログとは違う粒度でログとして残
しつつアウトプットする場として
Issue だけ使ってる

87. おわりに

88. ささいなスクリプトでも使われることを意識して
公開していけば目の前の問題は明確になり、他の
誰かの問題も解決できるかもしれない

89. 誰かの作ったスクリプトも
目的を理解して今まで以上に使いこなせるように
なって、そんな行動がきっと自身の可能性を広げ
て行いきます

90. たった一ファイルの
python スクリプトから始める
OSS開発
一緒にやっていきませんか？