コンテナとWebアセンブリがうまく連携する理由

編集者注:Docker + Wasmテクニカルプレビューが利用可能になりました。 プレビューの詳細を確認して 、 自分で試してみてください!

—

開発者は、アプリケーションを構築、出荷、およびデプロイするときに、最も抵抗の少ないパスを好みます。 コンテナ化が存在する理由の1つは、開発者がコードと依存関係をバンドルすることでクロスプラットフォームアプリを簡単に実行できるようにするためです。

私たちはDocker DesktopとDocker Hubでそれに基づいて構築しましたが、World Wide Web Consortium(W3C)のような他のグループも補完的なツールを作成しました。 これがWebAssembly(別名「Wasm」)が生まれた方法です。

WasmはDockerの代替品であると主張する人もいますが、実際にはWasmをコンパニオンテクノロジーと見なしています。 WebAssemblyを見てから、WebAssemblyとDockerが一緒になって今日の要求の厳しいワークロードをどのようにサポートできるかを掘り下げてみましょう。

ウェブアセンブリとは何ですか?

WebAssembly は、移植可能なコンパイル ターゲットにコードをパッケージ化するためのコンパクトなバイナリ形式です。 JavaScript、C ++、およびRustの互換性を活用して、開発者がクライアント/サーバーWebアプリケーションをデプロイするのに役立ちます。 クラウドのコンテキストでは、Wasmはファイルシステム、環境変数、またはシステムクロックにもアクセスできます。

Wasmは 、ステートレスでブラウザでコンパイルされたWebAssemblyコードを含むモジュールとホストランタイムを使用して動作します。 ゲスト アプリケーション (別の種類のモジュール) は、これらのホスト アプリケーション内で実行可能ファイルとして実行できます。 最後に、WebAssembly System Interface (WASI) は、標準化された API セットを提供して、より優れた機能とシステム リソースへのアクセスを可能にします。

開発者は、WebAssembly と WASI を使用して、次のようなことを行います。

• クロスプラットフォームのアプリケーションとゲームを構築する
• プラットフォームとアプリケーション間でコードを再利用する
• WasmとWASIでコンパイル可能なアプリケーションを1つのランタイムで実行する
• WebAssemblyファイルを依存関係とコードの単一のターゲットにコンパイルする

WebAssemblyはコンテナ化された世界にどのように適合しますか?

Dockerに精通している場合は、すでにいくつかの類似点が見られるかもしれません。 そして、それは大丈夫です! FermyonのCEOであるMatt Butcherは、 DockerとWasmが協力 して非常に強力な開発成果を達成する方法を説明しました。 クラウドコンピューティングの台頭を考えると、ハードウェア上でソフトウェアを安全に実行する複数の方法を持つことが重要です。 これが、DockerコンテナやWasmのような仮想化された分離されたランタイム環境を非常に便利なものにしている理由です。

マットは、Dockerの共同創設者であるSolomon HykesのDockerとWasmに関する元の ツイート を強調していますが、Wasmに関するSolomonのフォローアップメッセージについてすぐに言及しています。 これにより、近い将来、DockerとWasmがどのように連携するかが明らかになります。

「それで、wasmはDockerに取って代わりますか?」いいえ、しかし、DockerがLinuxコンテナ、Windowsコンテナ、wasmコンテナを並べて実行する未来を想像してみてください。 時間が経つにつれて、wasmは最も人気のあるコンテナタイプになる可能性があります。 Dockerはそれらすべてを等しく愛し、すべて🙂 を実行します https://t.co/qVq3fomv9d

— ソロモン・ハイクス (@solomonstre) March 28, 2019

したがって、DockerとWasmは、クラウドコンピューティングとマイクロサービスがより高度になるにつれて、敵ではなく友人になることができます。 マットがこのテーマについて共有したいくつかの重要なポイントは次のとおりです。

ユースケースでテクノロジーの選択を促進

そこにある非常に多様なユースケースは、1つのツールの機能をはるかに超えていることを覚えておく必要があります。 これは、Dockerが一部のアプリケーションに最適であり、WebAssemblyが他のアプリケーションに最適であることを意味します。 Dockerはクロスプラットフォームのクラウドアプリケーションの構築と展開に優れていますが、Wasmはブラウザベースのアプリケーション用のポータブルなバイナリコードのコンパイルに適しています。

開発者は、マルチアーキテクチャビルドを作成する際にWebAssemblyを長い間支持してきました。 これはWasmユーザーにとって依然として障害ですが、 Docker Buildxの発売により、比較ギャップは狭まりました。 これにより、開発者はWasmを使用する場合と非常によく似た結果を得ることができます。 このプロセスの詳細については、 最近のブログ投稿をご覧ください。

プレゼンテーションの中で、Matt は「コンピューティング インフラストラクチャの 3 つの異なるカテゴリ」と呼ばれるものを紹介しました。 それぞれが異なる目的を果たし、現在と歴史的の両方で独自の関連性があります。

• 仮想マシン(ヘビー級クラス )–別名クラウドの「主力製品」であるVMは、オペレーティングシステム全体(カーネルとドライバー、およびコードまたはデータを含む)をパッケージ化して、互換性のあるハードウェアで仮想的にアプリケーションを実行します。 VMは、OSのテストやサーバーに関連するインフラストラクチャの課題の解決にも最適ですが、多くの場合、サイズが数GBであるため、起動が非常に遅くなります。
• コンテナー (ミドルウェイト クラス) – コンテナーを使用すると、すべてのアプリケーション コード、依存関係、およびその他のコンポーネントをパッケージ化し、クロスプラットフォームで実行することが非常に簡単になります。 コンテナイメージのサイズはわずか数十から数百MBで、数秒で起動します。
• WebAssembly(軽量クラス) –コンテナよりも一歩小さいWebAssemblyバイナリはごくわずかで、安全なサンドボックスで実行でき、最初はWebブラウザー用に構築されていたため、ほぼ瞬時に起動できます。

Matt は、彼や他の多くの人々が、コンテナが次の大きなものとして VM を水から吹き飛ばすことを期待していたことをすぐに指摘します。 ただし、Dockerの人気が急速に高まっているにもかかわらず、VMは成長を続けています。 テクノロジーに関しては、ゼロサムゲームはありません。 DockerはVMを置き換えておらず、同様に、WebAssemblyはそれ以前のコンテナを置き換える準備ができていません。 マットが言うように、「それぞれにニッチがあります」。

業界の専門家はDockerとWebAssemblyの両方を賞賛します

最近のNew Stackの記事では 、これをさらに掘り下げています。 WebAssemblyがDockerをどのように置き換えることができるかに焦点を当てることは、これらの採用決定の背後にある主な推進力がビジネスユースケースである必要があるため、「要点を見逃しています」。 WebAssemblyの重要な利点の1つは、エッジコンピューティングを中心に展開しています。 ただし、Dockerコンテナは現在、エッジのユースケースとますます調和して機能しています。 たとえば、 エキサイティングなIoTの可能性が待っていますが、エッジコンテナはストリーミング、リアルタイムプロセス、分析、拡張現実など を強化することができます 。

ソロモンの以前のツイートを参照すると、DockerがWasmコンテナを実行することを想定するときに、彼はこれをほのめかしています。 秘訣は、どの アプリがどのテクノロジーに最も適 しているかを特定することです。 大量のファイルシステム制御とIOを必要とするアプリケーションは、Dockerを好む場合があります。 ソケットレイヤーアクセスが必要な場合も同様です。 一方、Wasmは、手間のかからないWebサーバーのセットアップ、簡単な構成、およびコストの最小化に最適です。

どちらのテクノロジーでも、開発者は新しいユースケースと既存のユースケースの両方を継続的に発掘しています。

ドッカーとワズムがチームを組む:気難しいウィスカーズゲーム

理論的なアプリケーションは有望ですが、実際の動作を見てみましょう。 講演の終わり近くで、マットは、セッションを開始するためにデモしたFinicky Whiskersゲームが実際にDocker、WebAssembly、およびRedisを活用していることを明らかにしました。 これらの3つのテクノロジーは、超高速のバックエンドを形成するゲームエンジンを構成しました。

Finicky Whiskers は 8 つの別々の WebAssembly モジュールに依存しており、そのうちの 5 つは Matt がセッション中にカバーしました。 この例では、ボタンをクリックするたびに、Web アプリ、マイクロサービス、およびサーバー アプリケーションを実行するための Fermyon のフレームワークである Spin に HTTP 要求が送信されます。

これらのクリックにより、ゲームの実行に役立つWasmモジュールが連続して生成されます。 これらのモジュールは、すべてのユーザーアクションにほぼ瞬時にスピンアップまたはシャットダウンします。 呼び出しの合計数は、モジュールごとに変わります。 モジュールは、アプリケーション内のコア機能をサポートする重要なファイルも取得します。 ゲームになりすましていますが、Finicky Whiskersは実際には負荷発生器です。

Docker コンテナーには、Redis と pubsub の実行中のインスタンスがあり、メッセージの仲介とキーと値のペアへのアクセスに使用されます。 これにより、クライアントとサーバーのブリッジが形成され、Finicky Whiskers が通信できるようになります。 モジュールは、Redis pubsub 実装にプッシュする前にデータ検証を実行します。 各モジュールは、ファイルサーバーとともに、このDockerコンテナ内のサービスと通信でき、DockerとWasmが共同でアプリケーションに電力を供給できることを証明します。

具体的には、Matt は Wasm を使用してマイクロサービスを迅速に開始および停止しました。 また、これらのサービスが単純なタスクを実行するのにも役立ちます。 一方、Dockerは状態を維持し、Wasmモジュールとユーザー入力間の通信を容易にするのに役立ちました。 これは、低リソース使用量、スケーラビリティ、長時間実行される部分、および負荷の予測可能性の完璧な組み合わせです。

コンテナとWebAssemblyは速い友達であり、致命的な敵ではありません

これまで見てきたように、コンテナとWebAssemblyはコンパニオンテクノロジーです。 一方は他方を打ち負かすためのものではありません。 これらは共存することを意図しており、多くの場合、非常に興味深いアプリケーションを強化するために連携します。 Finicky Whiskersは最も複雑な例ではありませんでしたが、この点を完全に示しています。

これらのテクノロジが際立っている場合は、独自のワークロードをサポートしているために際立っています。 あるテクノロジーが他のテクノロジーよりも優れていると宣言するのではなく、それぞれがどこにあるのかを疑問視するのが最善です。

Docker での Wasm の今後の展開を楽しみにしています。 また、Dockerには、Wasmアプリケーションでできる限り支援の手を差し伸べてもらいたいと考えています。 私たち自身の製品責任者であるジェイク・レバーンは、それを最もよく言います:

「WasmはDockerを補完するものです。開発者がアプリケーションの一部を設計および実装する方法が何であれ、Dockerは開発体験をサポートするためにそこにいます」とLevirne氏は述べています。

Dockerを使用する開発、テスト、およびデプロイツールチェーンにより、アプリケーションアーキテクチャに関係なく、アプリケーション配信のために再現可能なパイプラインを簡単に維持できるとLevirne氏は述べています。 さらに、何千もの公式および検証済みイメージを含む、何百万ものビルド済みDockerイメージは、「コアサービスのバックボーン(例: データストア、キャッシュ、検索、フレームワークなど)"Wasmモジュールと連携して使用できます。」

Docker HubでWebAssembly/Wasm イメージのコレクションも維持しています! Docker Desktop をダウンロードして 、これらのイメージの実験を開始し、Docker でサポートされる最初の Wasm アプリケーションの構築を開始します。コンテナランタイムとレジストリも、ネイティブのWebAssemblyサポートを含むように拡張されています。