このエントリは第6回Web System Architecture研究会の予稿です。
Serverspec：宣言的記述でサーバの設定状態をテスト可能な汎用性の高いテストフレームワークでは、従来手法を補うための要件を考察し、要件を満たすために以下の様にテストフレームワークを2つに分割する手法を提案した。
そして、提案手法に基づき実装した汎用コマンド実行フレームワークをSpecinfra、制御テストフレームワークをServerspecと名付けた。
Specinfraを利用したより優れたテストフレームワーク実装の登場や、確認業務以外の運用業務に必要なコマンド群を体系化することによるテストフレームワーク以外への応用、例えば構成管理ツールへの応用も期待し、いくつかの実装も登場したが、Specinfraは期待したほど広く利用されていない。
本予稿では、Specinfraが期待ほど利用されていない要因について考察し、解決するための手法と実装について述べる。
サーバ管理系ツールを実装する場合、多くの環境をサポートしようとすると、以下の2つ違いについて考慮し、ツール内で違いを吸収するための抽象化を行うのが一般的である。
Chef, Puppet, Ansible, Itamae(Specinfra)といった似たような目的を持つサーバ構成管理ツールは、OS/ディストリビューションや実行形式の抽象化をそれぞれ独自に実装している。
Specinfra開発の狙いは、各サーバ管理ツールで独自に実装している抽象化部分をライブラリに切り出すことによって、ツール本体の実装の手間を省き、手軽に実装できるようにすることにある。
しかし、再利用性を考慮して開発したSpecinfraはそれほど広く使われていない。
再利用性を考慮して開発したSpecinfraがそれほど広く利用されていない理由のひとつは、SpecinfraがRuby製であるため、Ruby以外のプロジェクトでは採用できない、ということである。
この課題を解決するための手法として、OS/ディストリビューションの抽象化や実行形式の抽象化を行うためのライブラリを、SpecinfraのようなRubyGemではなく、様々な言語からも利用できる共有ライブラリという形で提供する。
そのための実装をlibspecinfraと名付けた。libspecinfraはさらに以下の実装に分類される。
1は実装途中だが、現在開発を停止している。SpecinfraをRustで再実装する形で実装しているが、名前は敢えて変えずにSpecinfraとしている。
2はRuby, mruby, Python用バインディングが存在するが、こちらも現在開発は停止している。
GitHub上のlibspecinfra OrganizationにあるexamplesリポジトリにはRuby, mruby, Rustのサンプルコードがある。
PuppetやChefやServerspecについて、話題にのぼることが少なくなっている。これはコンテナが広く使われるようになり、サーバの構成管理とテストのあり方が変わってきているためである。コンテナイメージの作成は、従来のサーバプロビジョニングと比較して簡素なため、サーバ構成管理ツールの重要性が低下し、それに伴いテストの重要性も低下している。
とはいえ、従来のようなサーバプロビジョニングがなくなったわけではなく、コンテナのプロビジョニングとコンテナ実行基盤のプロビジョニング、2つのレイヤーに分離された、と考えることができる。
libspecinfraの適用領域はコンテナ実行基盤のプロビジョニングであると考えている。しかしその領域において、libspecinfraのような抽象度の高さは本当に必要なのか、コンテナ実行基盤のプロビジョニング以外にも応用できる領域がないか、等について検討する必要がある。