Upload
kei-iwasaki
View
3.698
Download
6
Embed Size (px)
Citation preview
Kei IWASAKITwitter: @laugh̲kGithub: @laughkGMOペパボ ‒ 技術部所属最近は tetote というサービスの開発などの技術支援を行うペパボでは珍しく python & Django を触っている元MSPのWeb系インフラエンジニアペパボでも元々はインフラエンジニア
プログラムコードを書かないWeb系インフラエンジニアが python を通じてコードを書くようになり、その成果物をオープンにするようになった体験とその時の起こった技術的な広がりの話
※ 突っ込んだ技術的な話はありません
対象普段コードを書きたいと思ってもなかなかかけていない人将来的にもっとコードを書くことを自分の業務の中心にしていきたいと考えている人身近なスクリプトを公開していくことに興味がある人
特にWeb系インフラエンジニアの方
Outline1. 簡単な監視やオペレーションの自動化をはじめていたころの話2. コマンドラインツールの開発に乗り出して行った話3. github/PyPI に成果物をのせてみた話4. オープンにすることも自然になっていった話5. おわりに
数年前のお仕事サーバのお世話サーバの初期構築SSH経由のコマンドラインに寄るオペレーション機器の購入や遊休化などの資産管理的なことデータセンタでラッキング、ケーブリング障害対応
ドキュメント手順書(ここでこのコマンドを実行するなどをまとめたもの)Excel/Word
メールチェック送信元はだいたい人間じゃない
などなど
慣れてくればオペレーションのスキルもそこそこ上がるし、ドキュメントの書き方もわかってくる。でも日々の業務の延長線上だけで過ごしてといずれ技術者としてできる
ことが頭打ちになってくる
という危機感が日に日に強くなっていた
たしかに、サーバー構築自体は効率よくできるようになっているでもそれはエンジニアとして成長しているわけではなく、ただサーバーをつくるのがうまくなっているだけなんです
【後編】第5回ペパボテックカンファレンス~インフラエンジニア大特集~開催レポート より
Python に馴染めた書き方が矯正される分、時間を開けながら見てもそこまで苦労せずに読み書きできた雰囲気がシェルスクリプトと違って戸惑ったけど、それは最初だけだったLinuxサーバであればどこでも使えるのも大きかったデプロイツールとして有名な fabric も使いやすかった
この時意識していたこと無理矢理にでもコードを書く方向に仕事をもっていった
時間に余裕があるときは「これコード書いて楽できないか?」を考えて強引にでも手を動かす既に配置されてる監視スクリプトなど既存のコマンドの中身を覗いてみて参考にしたりもした緊急時やそれっきりではないとき「それシェル芸でいいじゃん」という気持ちをこらえる
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 が一番手に馴染んだ無理矢理でも業務で使い、少しずつできることが増え、技術的な広がりを実感してきたとはいえ場当たり的にコードを書いてるだけでは問題も出てきた
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
配布しやすいようにパッケージング
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
このとき得られたものパッケージングのノウハウGithub Enterprise 上で管理これまで煩雑になっていたツールの管理が一元化された各環境への配布が非常に楽になったヘルプやREADMEなど使ってもらうことも意識するようになった
ここまでまとめ 場当たり的にスクリプトを書いているうちはどこか「裏技」のような感覚があった使ってもらえるツールとして作りきってみるとプロダクトとして自分以外の人にも認識され、確実なノウハウ展開とフィードバック反映ができるようになった使ってもらうツールとして作るにはインストール方法や使い方など、単純な機能以外も気にすることが多かった
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
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 に乗っかっているコードをより身近なものと感じるようになった同時にオープンにすることに対する自分の中の敷居が一気に下がった
監視周りをどうにかしたいという状況になったクラウド環境のため新規で Nagios/Munin を入れるのはなかなかつらそうだったかといって Mackerel のような外部サービスは予算的に厳しい一般的には自動化周りのノウハウが枯れている Zabbix がよさそう!となった
オープンに検証
https://github.com/laughk/zabbix‒playbook‒ubuntu
Ansible Plyabook を公開した状態でつくり DigitalOcean でひたすら検証role として使うことを前提に書いたので、「イケるな!」となったらそのままプロダクション環境へ適応できた
アラート通知が課題にやりたかったのはSlack通知Zabbix側でもSlack側でも特に標準で用意はされていなかったいくつか公開されているスクリプトもあったけど「コピペして適宜編集よろしく!」というスタイル管理が煩雑になりそうで運用上あまり使いたくない
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にとどまらないものになってきている
自分のブログのテーマ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 だけ使ってる