出典について
この記事は、Benny Cornelissen氏によるOtto: a modern developer's new best friendを翻訳したものです。
Ottoとは？
HashiCorpによると、OttoはVagrantの後継という位置づけです。Vagrantはリリースされてからたくさんの変更が加えられていますが、大きな改善をしつつも、最初にリリースされた時とほとんど同じことを基本的にはやっています。Ottoを使えば、ローカル開発からデプロイまでのワークフロー全体を見直されることになるでしょう。
Ottoは本当にVagrantを置き換えることになるのか？
現時点ではそれはありません。実際には、otto devコマンドを実装するのにVagrantを使っているほどです。Ottoの意味は、物事の新しい見方を提供することです。Mitchell HashimotoはHashiConfのキーノートで「法典化 vs. 化石化」という言葉で適切に言い表しており、詳しくは後述します。今のところは、VagrantとOttoの両方を並べた状態で幸せにそれらを使うことができて、好みに合えばどちらかを選択することもできるということです。
法典化 vs. 化石化
これがOttoがなんであるかを完全に言い表していて、つまり新しいアプローチだということです。Vagrantを今まで使ったことがあるなら、仮想環境を作るためにVagrantfileを作らねばならないことをご存知でしょう。「ベースボックス」あるいはVMイメージをプルしてきて起動し、スクリプトかPuppetやChefのコードでプロビジョンします。それにより、どんなマシンで起動したかによらずvagrant upを実行すればいつでも全く同じようになる仕組みです。さらに、今日vagrant upしても今から5年後にやっても同じことになります。これがHashiCorpのいう「化石化」です。
HashiCorpは、Ottoでこの化石化を捨てようとしています。代わりに、「AppFile」というものを使って、開発者にアプリケーションを記述する方法を提供しようとしているのです。AppFileは以下のようになります。
application {
name = "otto-getting-started"
type = "ruby"
}
project {
name = "otto-getting-started"
infrastructure = "otto-getting-started"
}
infrastructure "otto-getting-started" {
type = "aws"
flavor = "simple"
}
ここで読者の皆さんが気づかれるだろうことは、AppFileにはプロビジョニングやベースイメージに関する記述がないという点です。アプリケーションを記述する代わりに、Ottoのジョブがそれ以外のことを現代風のベストプラクティスを使ってやってくれるのです。つまり、今日otto devを実行した時に最終的に得られる環境は、5年後にotto devを実行した時に得られるものとは違う可能性が高いということです。
これの何がいいのかと思われるかもしれません。そもそも、Vagrantは一貫性があり何度も実行できるセットアップ方法を提供してくれるからVagrantを使っていたわけです。予測できるということはいいことでしょう？答えはイエスで、もちろんそれはいいことです。一貫性があり繰り返し実行できる方法は残りはするのですが、Ottoは時を経て賢くなることができるので、新しいベストプラクティスを学ぶこともでき、あなたのAppFileの実装に最新のベストプラクティスを適用することになるのです。
開発者はデプロイしたい！
Vagrantはローカル開発環境やデモ環境を作るのにはかなりよくはたらいてくれますが、ビルドの機能や本番環境インフラの構築に関しては何も提供してくれません。しかし開発者はデプロイしたい。ビルドもしたい。また、場合によっては自分自身のインフラを構築したい時もあります(あるいは実際には、Ops部門がインフラを準備してくれるのを単に待ちたくないだけかもしれません)。今までもそれはできていました。Ottoが登場する前は、Packerを使って自分用のイメージやDockerコンテナを作れました。Terraformを使ってインフラも構築できました。また、アプリをデプロイする方法も見つけられたはずです(シェルスクリプトの出番！)。
しかし真剣に考えてみれば、これらのことをやるのに4つの別々のツールを学びたいと思う人なんているでしょうか？しかも、私はまだこれらを「結びつけるツール」であるConsulやVaultのことは話していません。つまり実際には自分で6つものツールに精通しなければならないということ！あり得ない！
Ottoの木の下で
では、Ottoはこれらをどのように直すのでしょう？それは、要するに全部を実装して仕舞えばいいのです。otto devを実行すると、OttoはVagrantを起動します。しかし、Vagrantfileは書く必要がありません。otto buildを実行すると、OttoはPackerを動かします。otto infraを実行すると、Ottoは直ちにTerraformのコードを書いてそれを実行します。そして最後に、otto deployを実行すると、Ottoはインフラに対するアーティファクトを生成し、諸々の処理(ConsulやVault)を全て処理してくれます。これらは全て今日のベストプラクティスに基づくものです。
現状の制限
Ottoはリリースされたばかりなので、まだできないことがたくさんあるのは明らかです。例えば、現在サポートされているインフラのタイプはAWSだけです。アプリケーションも、Docker、Go、PHP、Node.js、Rubyに限定されます。VagrantファイルとTerraformモジュールを用意してOttoに使い方を「教える」ならば「custom」タイプは選べます。自前のVagrantfileやTerraformモジュールを作るのは面倒に思えるかもしれませんが、そうやりさえすれば、Ottoをより賢くすることは比較的簡単だといえます。
インフラ部分をスキップできませんかね？
私が注目したいのは、otto infraを実行してインフラ部分を作る代わりに、既にあるインフラを使うオプションです。多くの企業では、開発者やプロダクトのチームにインフラを提供するプラットフォームチームがあるでしょう。従って、Ottoが既存のインフラを使えるなら素晴らしいことです。開発者はローカル開発環境をotto devで作り、otto buildでDockerイメージを作って、そのコンテナをotto deployでNomadにデプロイできるということになります。
カスタムなVagrantfileとTerraformのコードを書かなければならなくはなりますが、「custom」アプリケーションタイプを使えば、既に企業が持っている共有プラットフォームにOttoからデプロイするようにできます。しかし、Ottoにインフラ部分を構築させたくないだけで、エンドポイントを指定する2番目のオプションが欲しいのなら、面倒すぎる方法にも思えます。
パーソナルなDevOpsアシスタント
HashiCorpはOttoをVagrantを置き換えるものだとしています。私はOttoを、モダンな開発者の新しい友人と考えています。OttoはパーソナルなDevOpsアシスタントなのです。Ottoは今も賢く、そして時間が経つとさらに賢くなっていきます。しかしまだ今は、Ottoにはソーシャルなスキルがかけていて、既にあるプラットフォームチームとはうまく連携できません。誰も完璧に生まれてはこない、そうですよね？
(訳注) これは、Ottoのリリース記事 (日本語訳)を基にした記事なので、そちらも読むとより理解が深まります。
