Embed Size (px)
Citation preview
たった一ファイルのpython スクリプトから始めるOSS 開発入門PyCon JP 20162016‒09‒21 Wed
GMO Pepabo, IncKei IWASAKI
お前誰？
Kei IWASAKITwitter: @laugh̲kGithub: @laughkGMOペパボ ‒ 技術部所属最近は tetote というサービスの開発などの技術支援を行うペパボでは珍しく python & Django を触っている元MSPのWeb系インフラエンジニアペパボでも元々はインフラエンジニア
#pyhack
今日のお話
プログラムコードを書かないWeb系インフラエンジニアが python を通じてコードを書くようになり、その成果物をオープンにするようになった体験とその時の起こった技術的な広がりの話
※ 突っ込んだ技術的な話はありません
対象普段コードを書きたいと思ってもなかなかかけていない人将来的にもっとコードを書くことを自分の業務の中心にしていきたいと考えている人身近なスクリプトを公開していくことに興味がある人
特にWeb系インフラエンジニアの方
Outline1. 簡単な監視やオペレーションの自動化をはじめていたころの話2. コマンドラインツールの開発に乗り出して行った話3. github/PyPI に成果物をのせてみた話4. オープンにすることも自然になっていった話5. おわりに
1. 簡単な監視やオペレーションの自動化をはじめていたころ
もちろん最初から手を動かしてコードの力を活用できていたわけではない
数年前のお仕事サーバのお世話サーバの初期構築SSH経由のコマンドラインに寄るオペレーション機器の購入や遊休化などの資産管理的なことデータセンタでラッキング、ケーブリング障害対応
ドキュメント手順書(ここでこのコマンドを実行するなどをまとめたもの)Excel/Word
メールチェック送信元はだいたい人間じゃない
などなど
普通に過ごしているとプログラムはほぼ触らない
慣れてくればオペレーションのスキルもそこそこ上がるし、ドキュメントの書き方もわかってくる。でも日々の業務の延長線上だけで過ごしてといずれ技術者としてできる
ことが頭打ちになってくる
という危機感が日に日に強くなっていた
たしかに、サーバー構築自体は効率よくできるようになっているでもそれはエンジニアとして成長しているわけではなく、ただサーバーをつくるのがうまくなっているだけなんです
【後編】第5回ペパボテックカンファレンス～インフラエンジニア大特集～開催レポート より
手を動かさなきゃ！！！
少しずつ手をつけていったシェル芸も磨いてそもそものオペレーションスキルを上げた何度も同じことをすることはスクリプト化Perl も試してみたPython も触ってみた
Python に馴染めた書き方が矯正される分、時間を開けながら見てもそこまで苦労せずに読み書きできた雰囲気がシェルスクリプトと違って戸惑ったけど、それは最初だけだったLinuxサーバであればどこでも使えるのも大きかったデプロイツールとして有名な fabric も使いやすかった
この時意識していたこと無理矢理にでもコードを書く方向に仕事をもっていった
時間に余裕があるときは「これコード書いて楽できないか？」を考えて強引にでも手を動かす既に配置されてる監視スクリプトなど既存のコマンドの中身を覗いてみて参考にしたりもした緊急時やそれっきりではないとき「それシェル芸でいいじゃん」という気持ちをこらえる
少しずつ身についていったそこそこ複雑な作業であったり、シェルスクリプトがつらくなってきたらPython を使うようになっていった標準ライブラリの使い方も覚えていき、徐々に手に馴染むようになってきた
Python を使い始めて幅が広がった例
fabric による複数サーバに対するオペレーションの自動化
メンバーの増減に伴うあたたかみのある usradd (userdel) x 稼働サーバからの開放など
fabric による複数サーバに対するオペレーションの自動化fabfile.py:
from fabric.api import sudo
def useradd(): sudo('useradd -m -d /home/laughk laughk')
ユーザー追加
$ fab -H hostname1,hostname2,... useradd
複雑な状況のAkamaiのキャッシュパージ
Akamai の複雑な条件でのキャッシュパージPyPI に ccuapi というキャッシュ関連のAPIを扱うライブラリがある実際にあったケースは
http://<ドメイン名>/<アカウントID1>/<アカウントID2>/etc/...
シェルコマンドだけでは困難な調査
URLエンコードをした状態のファイルパスで255byte を超えるもの一覧を取得する
対象のファイル名一覧は find コマンド + fabric でリストファイルとして取得リストファイルのファイルパスを URL encode した状態ですべて評価python スクリプトは urllib, re, sets の標準モジュールだけで可能だった
バク速になった例
シェルスクリプトよりもパフォーマンスの面でよかった例find + xargs によるリネームよりも os/glob モジュールを使った python スクリプトのリネームのほうが早かった
少しずつにできることが増え技術的な広がりを感じ始めた
とはいえ広がりの限界もあった
書いたスクリプトは実行したサーバにそのまま放置されてしまい、結果自分でも存在を忘れがち過去の成果物をよその環境で使いたいと思ったときに移植するのが非常に面倒だったりするバージョン管理、構成管理がされないケースのほうが多い結果として秘伝のタレの一部と化すこともある
場当たり的なスクリプトの限界を感じ始めた
ここまでまとめ
ここまでまとめ 業務だけで得られる知識だけでは技術的に取り残されそうという危機感から手を動かし始めた業務にも使えそうなものを色々試してみて python が一番手に馴染んだ無理矢理でも業務で使い、少しずつできることが増え、技術的な広がりを実感してきたとはいえ場当たり的にコードを書いてるだけでは問題も出てきた
2. コマンドラインツールの開発に乗り出して行った話
状況に応じて機会を見つけてコードを書いたりしてみるもののどこか「裏技」のような感
覚が抜けきれないでいた
転機
「fabric 便利だけどもう少しワンライナーで気軽に使いたいねー」
「fabric 便利だけどもう少しワンライナーで気軽に使いたいねー」という声を聞く
※ 便利なので個人のオペレーション効率化でよく使っていた
「fabric.api.execute 使えば wrapper みたいなの作れるのでは」と思い始める
ということで作った
cmspkit
cmspkit
カラーミショップのインフラチームに在籍中に制作cmsp(カラーミーショップ) + kit(道具)日々の運用を便利にすることを目標に作ったもの主に role ごとのリモートコマンドをいい感じに実行してくれるカラーミーショップのインフラ環境に特化したものなので非公開
cmspkit
使っている技術の詳細についてはこちら
http://www.slideshare.net/laughk/3‒53764813
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 用オプション 実行するシェルコマンド指定する
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-
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
cmspkit
この時に気を使ったこと配布しやすいようにパッケージング共通踏み台サーバにはインストール「ツール作ったよー」ということを宣伝
cmspkit
配布しやすいようにパッケージング
pip install で入れれるようにする作業setup.py を含んだリポジトリを Github Enterpriseにおいたやり方は Python プロフェッショナルプログラミング第2版 の Part1 Chapter3 の 「Pythonプロジェクトの構成とパッケージ作成」の情報をもとに今だと @tell‒k さんの PyPIデビュー 2015 がものすごく参考になる
cmspkit
共通踏み台サーバにはインストール
他のチームメンバーが必ずログインする場所にセットアップすることですぐ試せるようにパッケージングのおかげで以下の通りでOK
$ pip install \> git+https://ghe-url.example.com/cmspkit/cmspkit.git
cmspkit
「ツール作ったよー」ということも宣伝
cmspkit
「ツール作ったよー」ということを宣伝
フィードバックももらえたりした
このとき得たもの
このとき得られたものパッケージングのノウハウGithub Enterprise 上で管理これまで煩雑になっていたツールの管理が一元化された各環境への配布が非常に楽になったヘルプやREADMEなど使ってもらうことも意識するようになった
なによりも
一つのプロダクトとして提供することでノウハウを確実に簡単に広められ、フィードバックもすぐに反映できた
ここまでまとめ
ここまでまとめ 場当たり的にスクリプトを書いているうちはどこか「裏技」のような感覚があった使ってもらえるツールとして作りきってみるとプロダクトとして自分以外の人にも認識され、確実なノウハウ展開とフィードバック反映ができるようになった使ってもらうツールとして作るにはインストール方法や使い方など、単純な機能以外も気にすることが多かった
3. Github / PyPI に成果物をのせてみた
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
この takosan のクライアントをつくってみた
kite‒string
kite‒stringhttps://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 同様社内向けにして公開するつもりもなかった
これ、公開してもいいのでは？
勢いでPyPIへ登録
takosan がオープンなものなのでいいやという軽い気持ちで PyPI に登録アップロード方法はググると結構古い情報が引っかかってしまったけど、プロフェッショナルPythonプログラミング第2版が参考に今だと PyPIデビュー 2015 一番良くまとまっている
公開したときの気持ち
https://memo.laughk.org/2015/06/07/kite‒string‒release.html
公開したときの気持ち
勢いで一つの目標を達成してしまった
ここでまとめ
ここでまとめ 自分で作ったものが単純な pip install で導入できてテンションあがったそして本当に便利これをきっかけに他の PyPI に乗っかっているコードをより身近なものと感じるようになった同時にオープンにすることに対する自分の中の敷居が一気に下がった
ツール自体は大して流行ったとかはは無いけれど、公開するという体験が精神的な障壁を取り除いた
完璧ではなかったものの自分の中でのブレイクスルーを感じた
4. オープンにすることが自然になっていった話
監視周りをどうにかしたいという状況になったクラウド環境のため新規で Nagios/Munin を入れるのはなかなかつらそうだったかといって Mackerel のような外部サービスは予算的に厳しい一般的には自動化周りのノウハウが枯れている Zabbix がよさそう！となった
オープンに検証
https://github.com/laughk/zabbix‒playbook‒ubuntu
Ansible Plyabook を公開した状態でつくり DigitalOcean でひたすら検証role として使うことを前提に書いたので、「イケるな！」となったらそのままプロダクション環境へ適応できた
アラート通知が課題にやりたかったのはSlack通知Zabbix側でもSlack側でも特に標準で用意はされていなかったいくつか公開されているスクリプトもあったけど「コピペして適宜編集よろしく！」というスタイル管理が煩雑になりそうで運用上あまり使いたくない
ということで作った
zbx2slack
zbx2slack
https://pypi.python.org/pypi/zbx2slack
実はたった1ファイルの Python スクリプトコマンドのオプションに通知したい情報を渡せばすべてが完結するもの最初から「公開して配布できるようにすることを前提」に書いた
zbx2slack を作るとき意識したこと使うことだけに集中してもらいたかった
利用者は中身をいじらなくてもいい通知に必要な情報は全部コマンドオプションで渡せる配布を極力簡単にするために1ファイルにすべてまとめたpip install するもよし、直接 wget してサーバにおくもよし
CentOS 6 (python2.6) も条件付きで考慮
この体験で得た気づき
この体験で得た気づき何らかのOSSソフトフェアを選定するときは、覗けるならばコードも読みつつ更新状況やGithubのIssueなど生きているのかを気にするようになった
オープンにすることが前提になることによって自分の環境特有のハードコーディングがなくなり、解決したい問題をより一般的に捉えるようになった
「これ公開しちゃまずそう」と思うことでも「一般的なこういうことをする技術」というところをきちんと切り出すことができれば案外自由にできる
1ファイルのスクリプトも、「こういう問題を解決する」「こういうことができるようになる」ということが満たせているのであれば十二分に公開する価値はある
OSSとして、自分のものとして取り組めるので好きな技術で開発できる
ここまでをまとめると
ここまでをまとめるとたった一つのスクリプトを書き捨てる程度から、Python を好きになりここまでやってくる事ができた確実にコードの力で何かを解決する力が身についてきているオープンにすることによって技術的な視野の広がりも体験して、Pythonにとどまらないものになってきている
おまけ
Python に限らず色々オープンにするようになった例
自分のブログのテーマhttps://github.com/laughk/pelican‒hss
静的サイトジェネレータ Pelican のテーマシングルページレイアウトで個人的に気に入るものがなかったので、フォークしてカスタムしたもの
Django チュートリアルをオープンにすすめてみるhttps://github.com/laughk/py3‒django‒tutorial
取り組んだ日付ごとにPRで管理後で自分で振り返ってみるのに便利だったりする
PCセットアップの記録https://github.com/laughk/dell‒xps15‒9550
ブログとは違う粒度でログとして残しつつアウトプットする場としてIssue だけ使ってる
おわりに
ささいなスクリプトでも使われることを意識して公開していけば目の前の問題は明確になり、他の
誰かの問題も解決できるかもしれない
誰かの作ったスクリプトも目的を理解して今まで以上に使いこなせるようになって、そんな行動がきっと自身の可能性を広げ
て行いきます
たった一ファイルのpython スクリプトから始めるOSS開発
一緒にやっていきませんか？
