Flynn: ツルしてみませんか？

これはgolang-nutsで議論されました。 私の印象では、いくつかの機能は似ていますが、コアの目標は異なります。

/ cc @fsouza

@titanousこのスレッドを見ました。 ツルとフリンの最大の違いがツルである場合は、ウェブに固有のものであり、少しの労力で変更できます。

2つのプロジェクトが一緒になれば、これらのプロジェクトにとってより良いものになり、rails + merbで起こったように、この新しいプロジェクト（tsuru + flynn）を作成および維持するためのより強力なコミュニティを構築しやすくなると思います。

現在、計画しているコンポーネントと目標を詳しく説明する、より完全な仕様に取り組んでいます。 私たちがその文書をプッシュするまで、この議論を建設的に延期することになると思います。

最後に、今の違いはもっとはっきりしていると思います。

違いは何ですか？ 私にはわかりませんが、実行されているすべてのPaaS作業を理解するために推奨できる情報源はありますか？

私は調査を通じてそれを理解しようと努めてきましたが、Dockerで作成されているPaaSシステムについて学び続けているだけで、物事は本当に断片化されているように感じます。 それに追いつくのは本当に難しいです...これらのシステムのそれぞれは、それが何であるかを実際に知る前に、セットアップと試行に時間と献身を必要とします-これで起こっているすべてのプロジェクトに精通するためのより簡単な方法はありますかそんなに時間がかからず、終わりのないうさぎの穴にならない空間？

私がこれまで見てきたことから、フリンはかなり甘く見えます-私はすぐにそれを試すことに興奮しています。

PSグーグルでここに来た「鶴フリン」

@keyvanfatehiご関心をお寄せいただきありがとうございます。

特に多くのプロジェクトがプライベートまたは一貫性のないロードマップに従っているため、そこにあるすべてのPaaSプロジェクトを最新の状態に保つことは困難です。 一般に、Flynnと他のほとんどのPaaSプロジェクトの違いは次のとおりです（tsuruとの直接の比較ではなく、一般的なスペースのみ）。

フリンはもっと野心的です。 Flynnは、ステートフルサービスを含め、Linux上で実行されるすべてのものを実行できます。 この機能を利用して、共通のデータベースをFlynnと一緒にパッケージ化するため、ほとんどのユーザーとプロジェクトがデータベースを手動で管理することはありません。 Flynnのコンポーネントはモジュール式であるため、再利用、変更、交換が簡単になり、ニーズに合った適切なソリューションを作成できます。 Flynnを、すべてのプロジェクトと組織の操作を「解決」する単一のツールキットにしたいと考えています。 ログの集約、メトリクス、継続的インテグレーション、ネットワーキングおよび開発ワークフローの次世代ソリューションなど、今後さらに多くのことが予定されています。

他のほとんど

Flynnが本番環境の安定性と機能の完成に達したら、プロジェクトごとに違いを文書化しようとします。

@danielsidersありがとうございます！ 皆さんがこの分野で革新するのを見るのを楽しみにしています。 私は間違いなくあまりにも多くの操作が肩にかかることに苦しんでいます（それが私がDockerとその周りのツールを見ている理由です）。 私は、いわば、opsが解決できると信じたいです...

これまでの私の経験では、deisのように見えるflynn-demoを（成功裏に）使用してきました（直接試したことはありませんが、herokuのような動作を示す素敵なループビデオがあります）。 したがって、この浅いレベルでは、deis、flynn、herokuは同じように見えます。

これは、プライベートロードマップの良い点です。おそらく、すべてのロードマップに頭を悩ませるのは少し早いと思います。 追跡し、違いを識別し、それぞれの努力を判断しようとするよりも、1つの努力に専念する方がはるかに簡単なようです...それぞれが革新的で興味深いものです！

とにかく、エキサイティングな時代-私がまだ完全に理解できなくても、これをすべて実現することに参加してくれてありがとう:)

@keyvanfatehiほとんどのPaaSは、アプリケーションのHerokuスタイル（git push）デプロイメントをサポートしています。 実際に異なるのは、デプロイできるアプリケーションの種類と、アプリのデプロイ後に何が起こるかです。

（nb：Flynnは、dockerpullやgitpullなど、他の多くのデプロイメントパラダイムもサポートしています。FTPでも難しくはありません）

@ keyvanfatehi 、
サービスについては、単一のアプリケーションで適切に処理するには具体的すぎます（データベース、nosql、redis、memcached、elasticsearch、オブジェクトストレージなどを処理するのがどれほど難しいか想像してみてください）。 サービスAPI（サービスを処理するためのビジネスロジックが配置される場所）を指定することをお勧めします。tsuruは、サービスの違いに関係なく、どのサービスでも同じように処理します。

私たちはとてもフレンドリーで、貢献や新しいアイデアに完全にオープンです。 単一のソリューションでflynnを使用するのは素晴らしいことだと思いますが（将来、flynnの理想に合うように鶴を拡張することもできます）、彼らは私たちと同じように野心的であるため、彼らの意見とビジョンを完全に尊重します:-)

TL; DR
私たちはサービスがいかに重要であるかを知っているので、その要件に対処するためのエレガントな方法を開発します。 Tsuruは、明確に定義されたサービスAPI（作成、削除、バインド、計画などのいくつかの単純なエントリポイントを使用）を使用して任意のサービスを処理できます。 したがって、特定のサービスのすべての複雑さは、独自のservice-apiによって処理されます。 Redis APIの例を示しましょう：＃tsuru service-add redis（servicename）redis_blognews（serviceinstancename）plus（plan）を実行すると、redis_blognewsという名前のredisインスタンスとplan plus（2つのインスタンスを提供する）が作成されます高可用性を備えたredisの）。 Tsuruは、どのように作成されるか（高可用性がある場合でも）、service-apiによって完全に処理されます。 また、tsuruコードに触れることなく、そのためのservice-apiを作成するだけで外部（プロプライエタリ）サービスを使用することもできます。 したがって、サービスを処理する方がはるかに柔軟であり、鶴でその複雑さが増すことを回避できます。 その後、＃tsuru bind redis_blognews --app yourblognewsappを使用できます。そうすると、tsuruはサービスのクレデンシャルをアプリケーションに挿入します。

私はPaaSに不慣れで、混乱しています。 鶴を選んで少しいじっています。 フリンの目標とそれほど変わらないように思えます。 サービスAPIを使用してステートフルなものを実行できます。これは非常にモジュール化されており、tsuru-api、docker-cluster、gandalfなどがあります。

努力を組み合わせることで、より良い製品がもたらされるのではないかと私はまだ思っています。

ここで@msabramoに同意する必要がありますが、Tsuruのすべての機能を備えた新しいPaaSを構築する理由についてはまだ良い点がわかりません。 私はまた、努力を組み合わせることで素晴らしい製品が生まれることにも同意します。