WSA 研 #1 予稿 "再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み"
第1回WSA研究会 という催し物に出る予定でそれ用の予稿を書いたのですが、折角なのでブログにも掲載しておこうと思います。あとで更新するかもです。
再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み
Infrastructure as code や CI/CD の文化の広がりやインフラ構成の複雑化に伴い、 Test Driven Infrastructure といったインフラ構成をテスト可能にすることで安定稼働を目指す取り組みがなされている。
Test Driven Infrastructure の実践方法としては 1) Ansible や Chef などといった構成管理ツールに特化したテストツールを使う 2) Serverspec などといった構成管理ツールとは独立したツールを使う方針が考えられるが、前者はツールに非常に依存しかつ独特の DSL を要求される、後者はツール特有の学習コストが要求されるといった課題がある。
実践方法とは別に、インフラ構成やテストに関する情報を残すことも重要である。これは Google の Site Reliability Engineering の序論に記されている "実装は一時的なものだが文書化された理論は重要" との記述や、 Serverspec が可読性を重要視 して実装されたことからも汲み取れる。
本研究ではこれらの背景を加味しつつ、前述の実践方針の 2) のような構成管理ツールとは独立した形で、かつ低い学習コストで Test Driven Infrastructure を目指す。 その実現方法として現在、 Harmonium というツールを試験的に実装している。このツールは現状、 Markdown に埋め込まれたシェルスクリプトを実行するツールである。 Harmonium によるテストコードの実行は bats と似たアプローチであるが、ドキュメントを Markdown で書けてかつ独自の記法を要求しないという差分がある。 Markdown は GitHub などのサービスの WebUI 上でレンダリング可能で運用上親和性も高く、テストコードに対する情報を付与しやすい。またシェルスクリプトを用いることで運用者はシェルの知識をそのまま利用することが可能で、別途 Ruby や Serverspec などのシンタックスを習得する必要がなくなる。 現在 Harmonium は golang で実装しており、ツールはワンバイナリで実行可能となるため、 Serverspec をローカルで実行する際に発生する Ruby や依存ライブラリを導入する手間などが軽減される。
参考
参考にした文書やソフトウェア。本研究で提案する Harmonium は特に Jupyter Notebook に大きく影響を受けている。 Jupyter Notebook はノートブック形式で実装とは別に Markdown で文書を残し、他者と共有ができる。 Jupyter は Cloud Datalab でベースに用いられるなど、データ分析でよく使われるツールとなっている。
余談だが Harmonium はブラウザ自動テストのためのツール Selenium やアプリ自動テストのためのツール Appium に触発されて命名した。
