この記事は HashiCorp Advent Calendar 2015 の第22日目です（急きょ参加させてもらったので、公開日と1日ズレてます……）。
次世代システム研究室の DevOps ネタ担当の M. Y. です。今回は、2015年12月21日に開催された社内の研究発表会にて、HashiCorp の新ツール “Otto” に関する発表を行いましたので、その内容をご紹介します。
Otto とは、2015 年 9 月末に HashiCorp 社が発表した新しいツールです（参考：公式サイト、リリース時のブログ記事）。単一の設定ファイル “Appfile” で、開発環境と本番環境の両方を管理できる “The Successor to Vagrant” を目指したツールとのことで、リリース当時から気になっていました。
そこで今回の研究では、Hadoop クラスタを含むサービスの開発環境を想定し、Vagrant + Ansible を使った場合の設定と、Otto を使った場合の設定のサンプルを実際に作ってみました。そして、この 2 つの設定を比較し、設定量の削減に Otto がどれくらい貢献できるかを試算しました。その結果、今回作成したサンプルでは、設定ファイルの行数を約 74 ％削減できるという結果が得られました。コメント行なども含む行数なので、あくまで参考値とお考えください。
とはいえ、Otto はまだ version 0.1 で、ドキュメントに書いてあるが未実装、という機能が多いです。そのため、今回は Otto のドキュメントにある機能が一通り実装された場合を想定して、設定量を試算しています。試算の詳細は、スライドをご覧ください。
ちなみに、今回は Cloudera QuickStart VM を使いたかったので VirtualBox を使ったのですが、12 月になって Docker image 版が公開されてしまいました（参考：Docker is the New QuickStart Option for Apache Hadoop and Cloudera）。いずれ Docker 版の設定も作ってみたいと思います。
Otto を触ってみた感想
研究発表会では、「で、結局 Otto は使えそうなのか？ いつ頃になったら使えそうか？」というコメントを頂きました。まあ、一番気になるところだと思います。
個人的に、Otto のコンセプトは、すごく良いところを突いていると思います。ただ、実装としては、コンセプトの肝である dependencies 機能の大半が未実装なので、正直なんとも言えない状況です。例えば、現在の Otto 0.1.2 では、Docker コンテナを開発環境にデプロイすることはできますが、AWS にはデプロイできません（参考：解説：Otto 0.1で dependency (AppType = docker) を指定した場合の動作）。また、スライドにも書いたように、依存先の Vagrantfile の読み込みもうまくいかないようです。
それと、スライドの最後の方に書いたとおり、Otto の言うところの Centralization of Knowledge をどのように整備していくのかが気になります。例えば、現在の Otto は、ローカル環境では Ubuntu を起動するのですが、AWS では RHEL ベースの Amazon Linux を起動します。OS のデフォルトは、デプロイ先によって変わるのでしょうか？ このあたりの方針が定まらないと、ベストプラクティスの集約がなかなか進まないのでは、という印象です。この先の半年～1年くらいの動向が、Otto の成否を決めるのではないかと考えています。
色々不安はありますが Otto は魅力的なツールなので、今後もアップデート状況に注目してきたいと思います。
次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。インフラ設計、構築経験者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。