Reusable TDI infrastructure

Transcript

1. Reusable TDI infrastructure WSA Conference #1 @syu_cream

2. Agenda • 背景 • 提案手法 • 設計 • 実装 •

   ~~評価~~ そんなものはない(´･_･`) • 議論したいこと

3. whoami • @syu_cream • SRE @ メルカリ • C++, mruby,

   Golang, etc • SF小説, 猫

4. 背景 • インフラ構成管理方法は多様化・複雑化してきている ◦ 思想として 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 など他ツールとは独立した基盤

5. 課題 • 構成管理ツール特化の基盤を用いる場合 ◦ そのツール特化の記法や制約に縛られる ◦ 他ツールへの移行時のネックになる • 他ツールとは独立した基盤を用いる場合 (特に

   Serverspec を意識...) ◦ Ruby や RSpec, Serverspec の resource type, matcher など覚えることは多々ある ◦ ローカルで動かす場合は Ruby + gem’s インストール, リモートで動かす場合は ssh できる必要がある

6. (一般的ではない経験上の)課題 • 構成管理ツール特化の基盤を用いる場合 ◦ Chef はそれ自体が複雑なのでそれ前提のテスト書きたくない ... • 他ツールとは独立した基盤を用いる場合 (特に

   Serverspec を意識...) ◦ Serverspec の為だけに Ruby+gem’s を本番サーバに入れたくない事例もあった ◦ 複雑なテスト書くと結局可読性低まる ◦ 場合によってはモニタリングの領域と被る • インフラのテストは誰がメンテするの？問題 ◦ Ruby, Python などで書いたテストは誰が読み書きできるのか

7. 提案手法 • ドキュメント + テスト用シェルスクリプトのセットで構成 ◦ インフラ担当者なら少なくともシェルスクリプトはいじれるはず（要出典） ◦ Markdown でドキュメント書けば

   GitHub でレンダリングもしてくれる • シングルバイナリの実行ファイル ◦ メンテナンス、デプロイが少し楽になる、かも • ドキュメント + スクリプト例） Jupyter Notebook ◦ http://jupyter.org/ ◦ データ分析の分野で広く使われ、 Cloud Datalab のベースにもなっている

8. 提案するテストの運用イメージ 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 テストの実装より、テストに関する情報を重視し記録していきたい

9. 実装 • Harmonium(ハーモニウム) ◦ https://github.com/syucream/harmonium ◦ Go で実装された、 Markdown 埋め込みシェルスクリプトを実行するツール

   ◦ シングルバイナリ、 go get でかんたん取得 ◦ シェルスクリプトは コードブロック “```” で囲まれることを想定 ◦ （レポート機能は弱い

10. Harmonium 利用イメージ 例） nginx が動作する Load Balancer の動作確認イメージ コマンドとドキュメントの記録 GitHub

    で管理 Harmonium でコマンド実行して結 果を取得

11. 現在の実装詳細 1. 正規表現で 文書のうち “```sh” と “```” で囲まれた行を取得 2. Tmpfile

    として取得した行をファイルとして出力 3. シェルスクリプトを実行 4. exit code を見て成功/失敗を判断

12. 今後の課題 • Harmonium について ◦ 評価や既存手法サーベイなど、研究でよくある課題をやる ◦ レポート機能を充実する ◦ 方向性変えて

    Jupyter とか既存ツールに組み込む形にしてもいいかも (?) • TDI 全般について ◦ 今回の Harmonium の話は思考実験的な提案。もっと良い道を模索したい ◦ 普段通り運用作業をしていくとテストコード（の候補？）が自動生成されるとか ◦ Docker image でインフラ構成が固められるように、テストもあるインフラの状態を固めて後で実行とか (?)

13. 余談: 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 のコードを書くのもコストがかかるし、もっと別の道が無いか模索したかった

14. 議論したいこと #1 • TDI に関連しそうな領域でみなさんが現在どうしているか /課題が何か知りたい ◦ 何のツールを使ってる？ ◦ どんなテストをしている？

    ◦ 何年継続して運用している？ ◦ メンテできている？

15. 議論したいこと #2 • WSA 絡みで先行研究を調べる場合はどうすると良いか？ ◦ 今回は存在する OSS や書籍を引用 ◦

    その他 USENIX LISA, SRECon は少し覗いたが実践的な内容 • SOSP, OSDI, NSDI あたりをやはり参考にする？

16. 議論したいこと #3 • WSA 研みたいな活動について ◦ 今後気軽に相談・議論できる場が欲しい ◦ 毎回の開催の他に Twitter/Slack

    などで議論できる文化を作って行っても良さそう ◦ (誰かが先に話題に上げたらこの話はスキップ )