オットー、浮浪者相続人に会う

OttoはVagrantの論理的な後継者であるHashicorpの新製品であり、クラウドテクノロジーの現代世界でプログラムの開発と展開のプロセスを簡素化するように設計されています。 問題に対する概念的に新しいアプローチ、実証済みの技術、オープンソース。 個人用DevOps開発アシスタント。

はじめに

有名なVagrantであるHashicorpの創設者であるMitchell Hashimotoの最初の製品は、開発プロセスの自動化とプログラムの展開のための高品質製品のチェーン全体の基盤を築きました。 Packerは、VirtualBox、Docker、Google Cloudなど、仮想マシンの最終イメージの作成を支援します。 Terraformは、特定のプロバイダーを参照せずに、クラウドでインフラストラクチャ全体を構築する複雑なプロセスを作成し、構成レベルにもたらします。 ConsulとSerfは、クラウドでの通信（サービスの発見、クラッシュの監視など）を担当します。 Vaultは、秘密、パスワード、機密データの信頼性の高い分散リポジトリであり、監査、アクセス制御、キーの取り消しが可能です。



これらの製品はすべてオープンソースであり、Goで記述され、直感的なインターフェイスとAPIを備え、作成されたタスクを適切に実行するため、非常によく書かれ、文書化され、インストールが簡単です。 正しく使用すれば、これらを組み合わせて使用​​することで、マイクロサービス、クラウド、仮想マシン、コンテナーを扱う現代の開発者の生活が大幅に促進されます。



開発者は、クラウドで簡単なことをするためにdevops-prosである必要はもうありません。上記のプログラムは、自分自身の主な頭痛の種を取り、別のdevops-departmentに移行しようとします。 それでも、これらはマスターする必要がある6つの個別のプログラムであり、ドキュメントを読んで学習します。 これは、「[ruby / php / etc]を[aws / gae / do / etc]にデプロイする方法」というリクエストを発行するGoogleの最初のページからの昔ながらのコピーペーストが、スタックのクラウドにデプロイする最も一般的な方法であるという事実につながります。



さらに、コピーペーストでも誰かのPacker / Terraform-configまたはVagrantfileでも、バージョンの変更、URLの変更、新しいプロトコルへの切り替えなど、遅かれ早かれそれらはすべて廃止されます。 さらに、最初のバージョンのVagrantユーザーは、アプリケーションを展開する機能の追加を求めています。 しかし、Vagrantfileはそのようなことを記述するための完全に異なるレベルの抽象化です。



これらすべてにより、ハシコープは問題に対する新しいアプローチが必要であるという認識に至りました。

コード化vs. 化石化

これらの用語を正しく翻訳する方法はわかりませんが、「ミイラ化」に対して「コーディング」をさせてください。 Hashiconf会議で両方の製品が発表されてから数日後、ニューヨークのDigitalOceanオフィスでOtto（およびHashicorpのシェダーであるNomad ）のプレゼンテーションに参加できたことは幸運でした。



Vagrant、Packer、Terraformが行うことは、開発環境をミイラ化することです。 プログラムの開発に必要なすべてのもの、すべての設定、リンク、およびコマンドを規定します。これにより、10年経っても、開発者は現在と同じ開発環境を1対1で開発できます。



しかし、10年後に、コンパイラまたはフレームワークの元のURLが既に変更されている場合はどうでしょうか？ または、世界は新しいYTTP3プロトコルに切り替えましたか？ 全員がVagrantファイルを更新する必要があります。 これで、Packerは画像をAmazonおよびDigitalOceanにアップロードする方法とVPCを作成する方法を知っているので、これを慎重に規定していますが、1年でAmazonがAPIを変更し、ネットワーク内に新しいセキュリティモデルを導入したり、Packerが自動的に行うその他のイノベーションを追加した場合/ terraformファイルは廃止されていますか？



Ottoは、この問題に対する概念的に新しいアプローチを提供します。これは、開発環境と展開を作成するプロセスを「コーディング」しています。 オットーに何をしたいかを伝えます（「Goの私のアプリケーションはAWSで実行し、mysql-baseと通信し、ポートをよく見る必要があります」）。オットーはさらに、すべての魔法を実行します。正しいことをしてください。



怖いですね。 よく見てみましょう。

詳細

ボンネットの下では、オットーは同じVagrant、Packer、Terraform、Consul、Vaultを使用しており、実際、それらの存在を知る必要さえありません。 何かがインストールされていない場合-便利な形式のオットーは、それらをダウンロードしてインストールするかどうかを尋ねます。



さらに、標準のワークフローはVagrantでの作業と非常に似ています。

• オットーコンパイル
• otto dev
• otto dev ssh

Ottoは1つのファイルのみを使用します-単純なケースでは、オットーはプロジェクトのタイプを推測できるなど、単純な場合でも必要ないAppfileです。 ファイル形式はHashikorp HCLで、読み取りと書き込みが簡単です。 アプリファイルの例：

application { name = "otto-getting-started" type = "ruby" } project { name = "otto-getting-started" infrastructure = "otto-getting-started" } infrastructure "otto-getting-started" { type = "aws" flavor = "simple" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

otto コンパイルフェーズはAppfileを読み取り、次のような.ottoサブディレクトリを（再）作成します。







これは、「コーディング」と「ミイラ化」の違いを反映する重要なポイントです。 Appfileが変更されるか、オットーが更新されるたびに、 オットー・コンパイル・コマンドはこれらすべてのフード内部を更新し、Vagrant、Packer、およびTerraformに必要な構成を作成します。 依存関係をインストールして環境を準備する方法の「ベストプラクティス」が変更された場合、コンパイル段階でotto-environmentが更新されます。 コンパイルコマンドを実行しない場合、ottoはコンパイル済みのAppfileのバージョンで動作します。



環境を準備する段階（ オットー開発 者）は、実際には、 浮浪者の初期化と浮浪者を置き換えます 。 仮想マシンが上昇します（これまでのところUbuntu hashicorp / precise64のみですが、将来OSにも選択肢があります）、ネットワークが構成され、SSHキー、依存関係、および必要なパッケージがインストールされます-一般的に、プロジェクトへの新規参入者が簡単に実行できるようにするすべての魔法otto dev sshコマンドを実行して、開発環境に入ります。



プログラムの準備ができたら、オットーはアプリケーションをクラウドにデプロイするタスクを引き受けることができます。 開発者は、Webサーバー、仮想プライベートネットワーク、およびその他の詳細設定の複雑さをすべて知る必要がなくなりました。 オットーを使用した展開サイクルは、インフラストラクチャの構築、アプリケーションイメージの構築、および実際の展開という3つのステップで構成されます。

• オットーインフラ
• オットービルド
• オットーデプロイ

ここでの「インフラストラクチャ」とは、クラウドサービスの特定の各プロバイダーに関連付けられたすべてのリソースを意味します。 otto infraは、サブネットを作成し、ルーティング、要塞ホスト、ゲートウェイ、VPCなどを構成します。これらは通常、多くのことを読んで、どのように機能するかを理解するのに長時間必要です。 Ottoはこのすべての負荷を自分で負担します。彼はすべてのベストプラクティスを順守して、これらすべてを処理する方法を「知って」おり、最適な方法でそれを実行します。 さまざまなインフラストラクチャオプションは「フレーバー」と呼ばれ、さまざまなオプションを説明します-「SSHアクセスを備えたクラウド内の単純なマシン」、「IPが外向きのプライベートネットワーク」など。 内部では、Terraformがすべてを実行します。



次のステップ「otto build」と「otto deploy」は、クラウドで実行する準備ができているイメージを収集し、インスタンスを起動します。 AMIコンテナまたはDockerコンテナ、またはottoが将来サポートする他のあらゆるコンテナです。



とても簡単です。 これで、PHPのWebサイトデザイナーでさえ、プロジェクトの同期、オットーの起動、クラウドでのWebサイトの起動が可能になりました。



さて、典型的な開発者ワークフローの最後は、 `destroy`コマンドです。

• オットデプロイ破壊
• オットーインフラ破壊
• otto dev destroy

繰り返しますが、オットーはクラウドテクノロジー、言語、およびフレームワークの開発および変更に伴い進化しますが、オットーを操作するための一連のアクションとアルゴリズムは変更されません。

マイクロサービス

現代のクラウドアプリケーションは、多くの場合、何らかの形でマイクロサービスアーキテクチャを使用し、各アプリケーションは他のアプリケーションに依存していることが多く、すべての依存関係を正しく上げることは非常に困難です。 Ottoもこの問題に取り組み、依存関係の概念を使用します。依存関係の概念はAppfileに記述され、依存関係URLの形式を持ち、これもまたottoプロジェクトです。 たとえば、プロジェクトがMongoDBに依存している場合：

 application { name = "otto-getting-started" type = "ruby" dependency { source = "github.com/hashicorp/otto/examples/mongodb" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

開発環境にログインすることで、DNSアドレス ` mongodb.service.consul`でmongodbにアクセスできます。

これはすべて、理論的には、多くの複雑な依存関係を持つサービスの開発を大幅に簡素化するはずです。

現在の制限

Ottoは1週間前にリリースされ、バージョン0.1であり、これまでのところ多くのことをサポートしていません。 現時点では、Go（PHP）、Docker（依存関係）、Node.js、Rubyのサポート（マジック）が実装されていますが、これも非常に制限されています。 現在、デプロイはAmazonでのみサポートされていますが、他のプロバイダーはまもなく追加されます。 オットー自体はこれを行わず、Azure、CloudFlare、DigitalOcean、GAE、Heroku、OpenStackなどをサポートするTerraformとPackerを使用するため、ここでは楽観的になります。



どこでもカスタムVagrantfileまたはTerraform-configsを指定することができます。これにより、非常に簡単で拡張性が高く、非常に非標準で洗練されたスキームにも適用できます。

結論

この記事を書いている時点では、オットーはまだ好奇心をそそっていますが、ボンネットの下のボンネットの下で非常によくテストされたツールを使用しています。 オットー自体のアイデアに関しては、開発者向けの魔法のDevOpsアシスタントがそれ自体を証明し、時間が経てばわかるでしょう。



個人的には、ハシコープの活動は、長い間私に一つの印象を与えました。彼らは何をしているかを知っていて、ゆっくりですが確実にこの目標に向かって動きます。 ミッチェルはスピーチの中で、オットーのアイデアは長い間あると言っていましたが、このレベルのプロジェクトをゼロから作成することはできないと理解していました。 したがって、毎年、その実装のために地面、キューブを準備しました。 ところで、 遊牧民もこれらのサイコロの1つであり、まもなくオットーでもサポートされます。



さらに、開発は非常に活発であり、Hashicorpのコードは非常に高品質であり、Hashimotoの生産性に関する伝説は人気があり、過去数年で素晴らしい進歩を見せています。 Hashicorpは、クラウドでの作業の利便性のためにエコシステム全体を作成します。



そのため、指をパルスに合わせてください。

参照資料

Ottoには優れたWebサイトとドキュメントがあります： www.ottoproject.io

Hashicorp Webサイト： hashicorp.com