Reusable TDI infrastructure WSA Conference #1 @syu_cream

Agenda ● 背景 ● 提案手法 ● 設計 ● 実装 ● ~~評価~~ そんなものはない(´･_･`) ● 議論したいこと

whoami ● @syu_cream ● SRE @ メルカリ ● C++, mruby, Golang, etc ● SF小説, 猫

背景 ● インフラ構成管理方法は多様化・複雑化してきている ○ 思想として Infrastructure as code, CI/CD, ... ○ ツールとして Ansible, Chef, Docker(+ k8s), … ○ 連携サービスとして AWS, GCP, ... ● Test Driven Infrastructure(TDI) が普及してきている ○ ref. https://www.ibm.com/developerworks/library/a-devops5/ ● TDI を実践する基盤も存在 ○ ChefSpec など 構成管理ツール特化の基盤 ○ Serverspec, bats など他ツールとは独立した基盤

課題 ● 構成管理ツール特化の基盤を用いる場合 ○ そのツール特化の記法や制約に縛られる ○ 他ツールへの移行時のネックになる ● 他ツールとは独立した基盤を用いる場合 (特に Serverspec を意識...) ○ Ruby や RSpec, Serverspec の resource type, matcher など覚えることは多々ある ○ ローカルで動かす場合は Ruby + gem’s インストール, リモートで動かす場合は ssh できる必要がある

(一般的ではない経験上の)課題 ● 構成管理ツール特化の基盤を用いる場合 ○ Chef はそれ自体が複雑なのでそれ前提のテスト書きたくない ... ● 他ツールとは独立した基盤を用いる場合 (特に Serverspec を意識...) ○ Serverspec の為だけに Ruby+gem’s を本番サーバに入れたくない事例もあった ○ 複雑なテスト書くと結局可読性低まる ○ 場合によってはモニタリングの領域と被る ● インフラのテストは誰がメンテするの？問題 ○ Ruby, Python などで書いたテストは誰が読み書きできるのか

提案手法 ● ドキュメント + テスト用シェルスクリプトのセットで構成 ○ インフラ担当者なら少なくともシェルスクリプトはいじれるはず（要出典） ○ Markdown でドキュメント書けば GitHub でレンダリングもしてくれる ● シングルバイナリの実行ファイル ○ メンテナンス、デプロイが少し楽になる、かも ● ドキュメント + スクリプト例） Jupyter Notebook ○ http://jupyter.org/ ○ データ分析の分野で広く使われ、 Cloud Datalab のベースにもなっている

提案するテストの運用イメージ SRE/Infra 日々の運用作業 テスト関連 ノウハウ文書化 文書から テスト実行 “Implementations are ephemeral, but the documented reasoning is priceless.” , from Foreword of SRE book. http://landing.google.com/sre/book/chapters/foreword.html テストの実装より、テストに関する情報を重視し記録していきたい

実装 ● Harmonium(ハーモニウム) ○ https://github.com/syucream/harmonium ○ Go で実装された、 Markdown 埋め込みシェルスクリプトを実行するツール ○ シングルバイナリ、 go get でかんたん取得 ○ シェルスクリプトは コードブロック “```” で囲まれることを想定 ○ （レポート機能は弱い

Harmonium 利用イメージ 例） nginx が動作する Load Balancer の動作確認イメージ コマンドとドキュメントの記録 GitHub で管理 Harmonium でコマンド実行して結 果を取得

現在の実装詳細 1. 正規表現で 文書のうち “```sh” と “```” で囲まれた行を取得 2. Tmpfile として取得した行をファイルとして出力 3. シェルスクリプトを実行 4. exit code を見て成功/失敗を判断

今後の課題 ● Harmonium について ○ 評価や既存手法サーベイなど、研究でよくある課題をやる ○ レポート機能を充実する ○ 方向性変えて Jupyter とか既存ツールに組み込む形にしてもいいかも (?) ● TDI 全般について ○ 今回の Harmonium の話は思考実験的な提案。もっと良い道を模索したい ○ 普段通り運用作業をしていくとテストコード（の候補？）が自動生成されるとか ○ Docker image でインフラ構成が固められるように、テストもあるインフラの状態を固めて後で実行とか (?)

余談: mruby で Serverspec ● 以前 mruby-cli でワンバイナリで実行可能な Serverspec 作った ○ http://syucream.hatenablog.jp/entry/2017/06/11/162012 ○ https://github.com/syucream/sssspec ● mruby-specinfra を利用 + mruby-rspec, mruby-serverspec を自前で実装 ○ 自前 mrbgems は PoC 的に一部しか実装していないのでまるで機能が無い！！！ ● 継続して開発はしなかった ○ libspecinfra の話が上がり始めてて、少し様子を見たかった ○ Serverspec のコードを書くのもコストがかかるし、もっと別の道が無いか模索したかった

議論したいこと #1 ● TDI に関連しそうな領域でみなさんが現在どうしているか /課題が何か知りたい ○ 何のツールを使ってる？ ○ どんなテストをしている？ ○ 何年継続して運用している？ ○ メンテできている？

議論したいこと #2 ● WSA 絡みで先行研究を調べる場合はどうすると良いか？ ○ 今回は存在する OSS や書籍を引用 ○ その他 USENIX LISA, SRECon は少し覗いたが実践的な内容 ● SOSP, OSDI, NSDI あたりをやはり参考にする？

議論したいこと #3 ● WSA 研みたいな活動について ○ 今後気軽に相談・議論できる場が欲しい ○ 毎回の開催の他に Twitter/Slack などで議論できる文化を作って行っても良さそう ○ (誰かが先に話題に上げたらこの話はスキップ )