これは未来です

こんにちは



クラウドテクノロジーに関するユーモラスな投稿の翻訳： It's The Futureです。 あらゆる種類の修正やアドバイスを歓迎します。











おい！ こんにちは 私の上司はあなたに話すように言った。 彼はあなたがウェブアプリケーションについて多くを知っていると言った。



-はい、今では事実です。分散システムに関心があります。 ContainerCampとGlueConで戻ってきたばかりで、来週はDockerConにも行きます。 ビジネスがどのように動いているかに本当に感動しました-すべてがはるかにシンプルで手頃な価格になります！ これが未来です！



うわー...わかりました、私は今、シンプルなWebアプリケーションを開発しています-通常のCRUD on Rails、Herokuにデプロイします。 教えてください、Herokuはまだ関連していますか？



-あなたは何ですか！ いや これはすでに古い学校です。 Herokuは死体です。 誰ももう使用していません。 今、あなたはDockerを知る必要があります。 これが未来です！



ああ、そうです。 大丈夫。 これは何？



-Docker-コンテナ化の新しい方法。 LXCのようなもので、コンテナパッキング形式のみが含まれています。また、分散プラットフォームと分散システムの構築を非常に簡単にする多数のユーティリティです。



保存？..-何のため？ LXEとは何ですか？



-LXC。 ステロイドのchrootのようなものです。



cher-ootとは何ですか？



-なるほど...見える... Docker ...コンテナ化...これは未来だ...仮想化のようなもので、より高速で安価なものだ。



Vagrantのように。



-いいえ、Vagrantは死体です。 コンテナ内で使用するための準備がすべて整いました。未来です！



それでは、仮想化について何も知る必要はありませんか？



-さて...いいえ、仮想化を理解する必要があります。 現時点では、コンテナは完全なアプリケーションデータ保護を提供していません。 そのため、すべてをマルチテナント環境で実行したい場合は、ユーザーがサンドボックスから出ないようにする必要があります。



だから、何かが迷子になった。 少し巻き戻しましょう。 そのため、コンテナと呼ばれる仮想化があります。 これをHerokuで使用できますか？



「まあ、HerokuはDockerをサポートしていますが、私があなたに言ったことを思い出してください。」 Herokuは死体です。 CoreOSでコンテナを実行する必要があります。



これは何ですか



-これは、Dockerで使用できる最もクールなホストOSです。 くそー、Dockerも必要ありません！ rktを使用できます！



ロケット



-いいえ、rkt。



そう、ロケット。



-いいえ、今ではrktと呼ばれています。 完全に異なるもの。 これは、Dockerの競合として提供されている代替のコンテナ化形式です。



あひるはかっこいい？



-もちろんクールです。 構成可能性は未来です！



このRKTを使用していますか？



「わかりません。」 誰もこれを使用しているとは思わない。



えーと...それでCoreOSについて何か言ったの？



-はい...ですから、これはDockerで使用するホストです。



ホストとは？



-CoreOSは、コンテナで最適に動作するように設計されています。 彼女はコンテナを操作するように構成されています。



コンテナを使用して...？



「はい、コンテナに何かあります。」 したがって、「Amazon EC2のようなインスタンスを発生させる」と入力し、そこでCoreOSホストを発生させてから、Dockerサービスを開始し、Dockerイメージをそこにデプロイできます。



このすべてのどの部分がコンテナですか？



-このすべて。 見て、アプリケーションを取得して、Dockerfileを作成し、ローカルイメージを作成してから、Dockerホストをプッシュします。



ああ、ヘロクのように？



-いいえ... Herokuではありません。 Herokuは死体だと言いました。 Dockerを使用して独自のクラウドを起動します。



O_o？



-はい、それは本当に簡単です。 #gifeeについて読んでください。



Gify？



-GIFEEは、その他すべての人にとってのGoogleインフラストラクチャです。 コンテナを使用するこれらのユーティリティとテクノロジースタックをすべて使用すると、Googleと同じようにすべてのインフラストラクチャを使用できます。



なぜGoogleサービスを使用しないのですか？



-そして、半年ですべてが完全に変わるとしたら？



さて、誰もがこれをすべてホストしていませんか？ これをすべてホストしたくありません。



「まあ、AmazonECS、しかしあなたはある種のXMLでたらめを書かなければならない。」



OpenStackについて何が言えますか？



-フ...



聞いて、私は何も自分でホストしてサービスしたくありません。



-いいえ、本当に簡単です。 Kubernetesクラスターをセットアップしただけです。



クラスターが必要ですか？



-Kubernetesクラスター。 彼はすべてのサービスの展開を管理します。



サービスは1つしかありません。



-何を言ってるの？ 見て、Webアプリケーションを持っていますよね？ したがって、8〜12個のサービスが必要です。



なに？ いや！ 1つのアプリケーションがあります。 サービス、pohervis-気にしないでください！ たった1つのクソアプリ！



-いいえ、マイクロサービスに注目してください。 これは未来です。 これが私たち全員の今のやり方です。 超大型アプリケーションを使用して、12のサービスに分割します。 各タスクに1つ。



まあ、これは多すぎる...



「これは、構成が信頼できることを確認する唯一の方法です。」 認証サービスがクラッシュした場合...



認証サービス？ はい、e-May、以前に何度も使用したのと同じプラグインを使用するだけでした！



-スーパー。 それを使用します。 別のプロジェクトに入れてください。 彼のRestAPIの上に投げます。 その後、他のサービスはこのAPIを使用し、障害を非常に優雅に処理します。 コンテナに入れてCI / CDを作成してください！



あなたのやり方で。 今、私は数十の管理されていないサービスを手にしていますが、次は何ですか？



-はい、それで、私はKubernetesについて話しました。 これにより、すべてのサービスのオーケストレーションを簡単に行うことができます。



オーケストラ？



-はい！ まあ、あなたはあなたのこれらのサービスを持っている、そしてそれらはフォールトトレラントでなければならないので、あなたはあなたのサービスのそれぞれに対して一度にいくつかのコピーを実行する必要がある！ また、Kubernetesは、これらのコピーが十分にあり、フリート内のホスト間で配布され、常に利用可能であることを保証します。



つまり、フリートが必要ですか？



-はい、フォールトトレランス用。 しかし、Kubernetesはあなたのためにすべてを行います。 さらに、KubernetesはGoogleによって作成されたため、またetcdに基づいて機能するため、Kubernetesが正常に機能することを確信しています。



etcdとは何ですか？



-このことはRAFTに基づいて行われます。



OK、RAFTとは何ですか？



-パクソスのようなものです。



主よ、このうさぎの穴はどのくらい深くなるのでしょうか、今どこに行きますか？ ただ1つのクソWebアプリケーションを実行したいだけです。 お母さん!!! さて、深呼吸をして、息を吐きます... OK、パクソスとは何ですか？



-Paxosは、70年代からの分散プロトコルの古いファミリであり、誰も理解も使用もしていません。



いいね！ あなたがそれについて私に言ってくれてとてもうれしいです！ では、いかだとは何ですか？



-誰もPaxosを理解していないので...ええと...ディエゴを除いて...



ああ！ 彼を知っていますか？



-いいえ、もちろん、CoreOSで動作します。 いずれにせよ、ディエゴは博士号のためにラフトを思いついた。 Paxosは複雑すぎました。 くそ賢い人。 そして、彼はetcdを実装として書いて、それからAphyrはそれは本当にたわごとではなく、クールだと言った！



アフィールとは誰ですか？



-Aphyr-まあ、これは「Call Me Maybe」を書いた人です、まあ...彼を知っていますか？ 「分散システムとBDSM男」？



あなたはただBDSMと言いましたか？



-はい、BDSM。 これはサンフランシスコです。 ここの誰もが、分散システムとBDSMに情熱を注いでいます。



そして彼はそのケイティ・ペリーの歌を書いたのですか？



-いいえ、彼は各データベースがCAPで失敗するという事実に関する一連の記事を書きました。



CAPとは何ですか？



-CAPに関する定理（ビール醸造の定理としても知られています）。 彼女は、3つのポイントのうち、一貫性、アクセシビリティ、分割に対する抵抗の2つしかポイントを獲得できないと言います。



そして、すべてのデータベースがこのCAPをフラッディングしますか？ これは一体何を意味するのでしょうか？



「つまり、これはすべて最悪です。」 MongoDBに似ています。



MongoDBは水平方向に拡張可能だと思いました。



-あなた以外は誰もいません。



わかった では、etcdはどうなっていますか？



-はい、そう、etcdは値の分散ストレージです。



Redisと同じです。



「いいえ、Redisのようなものではありません。」 etcdは分散システムです。 ネットワークが一時的に失敗すると、Redisは情報の一部を失います。



まあ、これは分散バリューストアです。 なぜこれがそんなに便利なのですか？



-Kubernetesは、etcdをメッセージングバスとして使用して、標準の5ノードクラスターを構成します。 非常に安定したオーケストラシステムを提供するために、独自のサービスのペアと組み合わされます。



5ノット？ 1つのアプリケーションがあります。 このために何台の車を調達する必要がありますか？



-さて、12個のサービスを作成します。もちろん、それぞれに2、3個のバランサー、etcd、データベース、Kubernetesクラスターの追加コピーが必要です。 そのため、約50個の同時作業コンテナーになります。



ChZH！



-はい、最後に、質問はありません！ コンテナは非常に効率的であるため、8台のマシン間ですべてを簡単に配布できます。 それは素晴らしいことではありませんか？



それでも、これはあなたの印象に過ぎません。 そして、これらすべてを取り入れて、アプリケーションをデプロイすることはできますか？



-もちろん！ 確かに、DockerおよびKubernetesの場合、データストレージの量は未解決の問題であり、ネットワークの負荷は増加しますが、これらの問題はすぐに解決されます！



うーん、大丈夫。 さて、私は今すべてを理解していると思います。



-スーパー！



詳細な話をありがとう。



-はい、問題ありません。



私たちがお互いを理解していることを確認するために、私たちが話したことすべてを要約しておきましょう。



-もちろん！



したがって、単純なCRUDアプリケーションを12個のマイクロサービスに分割する必要があります。各マイクロサービスは独自のAPIでラップし、これらのAPIによって相互に呼び出す必要がありますが、同時に各エラーを処理し、これをすべてコンテナーに入れますDocker、CoreOSベースのDockerホストである8台のマシンのフリートを起動し、小さなetcdベースのKubernetesクラスターを使用して「オーケストレーション」し、ネットワーク負荷と情報ストレージに関する「未解決の質問のカップル」を解決し、複数のCI / CDを構成しますバランサー付きの各マイクロサービス 艦隊でvschikami。 そうですか？



-はい！ シックじゃない？



... Herokuにデプロイします。