WebAssembly (別名Wasm)が開発段階にあることは間違いありません。一部の人にとっては閃光のように思えるかもしれませんが、Wasmは継続的なコンテナ化された開発において重要な役割を果たしていると信じています。 DockerとWasmは補完的なテクノロジーになる可能性があります。
過去には、DockerがLinuxまたはWindowsコンテナと一緒に Wasmモジュールを正常に実行する方法を 調査してきました。 それから約 5 か月後、 Docker+Wasm テクニカル プレビューで新たな大きな一歩を踏み出しました。 開発者は、卓越したパフォーマンス、移植性、および実行時の分離をこれまで以上に必要としています。
DockerのエンジニアリングディレクターであるChris Croneと、Second State CEOの創設者であるMichael Yuanは、CNCFのWasm Day 2022で これらの問題点に対処 しました。 これが彼らの完全なセッションですが、私たちの凝縮された内訳に固執してください:
DockerとWasmを使用して正常に開発するために、新しいプロセスを学ぶ必要はありません。 一般的な Docker CLI コマンドでこれに対処できます。 Dockerは、WasmEdgeとのコラボレーションのおかげで、WebAssemblyランタイムを管理することさえできます。 この新しいプロジェクトを扱う理由と、それを可能にする技術的なメカニズムについて詳しく説明します。
なぜWebAssemblyとDockerなのか?
ワークロードとコードをどのように分離するかは、ソフトウェアをユーザーにどれだけ迅速に提供できるかに大きな影響を与えます。 Chris は、開発者がどのように評価しているかを説明することで、これを強調しています。
- プロジェクト間でコンポーネントと定義されたインターフェイスを簡単に再利用できるため、価値をより迅速に構築できます
- ワークロード間の安全で堅牢な境界を維持しながら、共有コンピューティングリソースを最大化し、アプリケーション配信のコストを削減
- コンテナイメージなどの便利なパッケージ化メカニズムを通じて、数秒でユーザーにシームレスなアプリケーション配信を行い、ユーザーが価値をより迅速に確認できるようにします
ワークロードの分離がこれらの役割を果たすことはわかっていますが、エアギャップ、ハードウェア仮想化、スタック仮想化(WasmまたはJVM)、コンテナ化など、それを実現する方法は数多くあります。 それぞれに長所と短所があるため、最適なソリューションを選択するのは難しい場合があります。
適切なツールを見つけることも非常に難しい場合があります。 CNCF ツールの状況だけでも飽和状態にあり、これらのツールが存在することに感謝していますが、その多様性は多くの開発者にとって圧倒的です。
クリスは、特殊なツールが目前のタスクを克服できると信じています。 これらのツールの決定を導くことも Docker の責任です。 これは、開発者がアプリケーションをできるだけ早く構築、共有、実行できるように支援するという継続的な使命に基づいています。
そこで、WasmEdgeとMichael Yuanの出番です。
Docker と WasmEdge によるエキサイティングな機会
Michaelは、コンテナとWebAssemblyのユースケースの間にいくつかの重複があることを示しました。 たとえば、両方の陣営の開発者がマイクロサービス アプリケーションを出荷したい場合があります。 Wasmは、起動時間の短縮とコードレベルのセキュリティを実現できるため、多くの場合に役立ちます。
ただし、WebAssemblyは、スレッド、ガベージコレクション、およびバイナリパッケージの制限により、すべてのユースケースに適合するわけではありません。 現在、Wasmでアプリケーションを実行するには、追加のツールも必要です。
動作中の WasmEdge : TensorFlow インターフェイス
その後、マイケルはTensorFlow MLアプリケーションのデモを開始し、WasmEdgeで何ができるかを示しました。 このアプリケーションは、他の WASI 互換ランタイムでは動作しません。
このデモを可能にしたいくつかの点:
- Rust:Wasmコンパイルターゲットをファーストクラスでサポートする安全で高速なプログラミング言語。
- Tokio:マルチスレッドなしで複数の並列HTTPリクエストを処理できる一般的な非同期ランタイム。
- ワスムエッジの TensorFlow: WASI-NN 仕様と互換性のあるプラグインです。 Tensorflowに加えて、PyTorchとOpenVINOもWasmEdgeでサポートされています。
手記： Tokio と TensorFlow のサポートは、他の WASI 準拠ランタイムでは利用できない WasmEdge の機能です。
Rustの cargo build コマンドを使用すると、ターゲットプラットフォームを使用して wasm32-wasi プログラムをWasmモジュールにコンパイルできます。 WasmEdge ランタイムは、結果の .wasm を実行できます ファイル。 アプリケーションが実行されたら、HTTPクエリを実行して、かなりクールな画像認識タスクを実行できます。
この例では、WASI 互換ランタイムとしての WasmEdge の描画を例示しています。 メンテナによると、「WasmEdgeは、クラウドネイティブ、エッジ、および分散型アプリケーション向けの軽量で高性能で拡張可能なWebAssemblyランタイムです。 サーバーレスアプリ、組み込み機能、マイクロサービス、スマートコントラクト、IoTデバイスを強化します。」
WasmをDockerでアクセス可能にする
Dockerには2つの魔法の機能があります。 まず、Dockerとコンテナは、本番環境のあらゆるマシンと場所で動作します。 第 2 に、Docker を使用すると、任意のプロジェクトからコンポーネントを簡単に構築、共有、再利用できます。 コンテナ・イメージおよびその他のOCIアーティファクトは、簡単に使用(および共有)できます。 隔離が焼き付けられています。 何百万人もの開発者は、次のような docker compose up多くのDockerワークフローにも非常に精通しています。
Chrisは、標準化とオープンエコシステムにより、Dockerとコンテナツールがどこでも利用できるようになった方法について説明しました。 ここではOCI仕様が非常に重要であり、ほぼすべての人とサポートされているテクノロジー(Wasmなど)で機能する新しいソリューションを作成できます。
一方、クロスプラットフォームのWasm開発者環境のセットアップには注意が必要です。 また、新しいツールやワークフローを学ぶ必要があり、生産性を妨げながらフラストレーションを生み出します。 私たちは、開発者がこれらの課題を克服するのを支援できると信じており、独自のプラットフォームを活用してWasmをよりアクセスしやすくできることを嬉しく思います。
Docker+WasmEdge のデモ
Wasmサポートは実際にどのように見えますか? Chris は、WASI をサポートする Docker Desktop のプレビューを使用してデモを開始しました。 彼は、次の 3 つのサービスを含む Docker 作成ファイルを作成しました。
- NGINX Docker Official Imageを使用したフロントエンドの静的 JavaScript クライアント
- にコンパイルされたRustサーバー
wasi/wasm32 - マリアDBデータベース
そのRustサーバーはWasmモジュールとして実行され、NGINXおよびMariaDBサーバーはLinuxコンテナで実行されます。 クリスは、ローカルプラットフォームからターゲットに wasm32-wasi コンパイルされたものを使用して Dockerfile 、このRustサーバーを構築しました。彼はまた、構築されたWasmモジュールを最適化するために、WasmEdge独自のAOTコンパイラを実行しました。 ただし、この手順はオプションであり、最適化されたモジュールには WasmEdge ランタイムが必要です。
ここでは、Chris (デモについては 19:43 を参照) に要点を任せます。 ただし、Composeビルドを実行してプラットフォームイメージを作成 wasi/wasm32 できることを知っておいてください。 実行する docker compose up と、アプリケーションが起動し、Web ブラウザーを介して操作できます。 これは、コンテナとWasmを並行してシームレスに実行する1つの方法です。
Docker CLI から、Wasm マイクロサービスが 2 MB 未満であることがわかります。 高性能のHTTPサーバーとMySQLデータベースクライアントが含まれています。 NGINXサーバーとMariaDBサーバーは、それぞれ10MBと120MBです。 あるいは、Rustマイクロサービスは、LinuxバイナリにビルドしてLinuxコンテナで実行した後、数十メガバイトになります。 これは、Wasm画像がいかに軽量であるかを強調しています。
出力はOCIイメージであるため、Docker HubなどのOCI準拠レジストリを使用して保存または共有できます。 複雑な新しいワークフローを学ぶ必要はありません。 また、Chris と Michael は WasmEdge を中心にしていますが、Docker はあらゆる WASI ランタイムをサポートする必要があります。
このアプローチはコンテナーと相互運用可能であり、Docker Desktop 内で早期にサポートされています。 Wasmは最初はなじみがないように見えるかもしれませんが、Dockerエコシステムとの統合により、その学習曲線がすぐに平準化されます。
Docker と Wasm の未来
クリスが述べたように、私たちはDockerとWasmをうまく連携させることに投資しています。 最近の Docker+Wasm テクニカル プレビューは、相互運用性を高めるための大きな一歩です。 ただし、Dockerツールが、目標に関係なく、Wasmに飢えた開発者の生活をどのように改善できるかを探ることにも興奮しています。
Dockerは、Wasmコミュニティに参加して、あなたのような開発者がWebAssemblyアプリケーションをどのように構築しているかをよりよく理解したいと考えています。 ユースケースと障害は重要です。 コンテナエコシステムの経験をコミュニティと共有することで、Wasmの成長を加速し、次の大きなプロジェクトに取り組むお手伝いをしたいと考えています。
始めて詳細をご覧ください
DockerとWasmをテスト実行してみませんか? ChrisのGitHubページで 、特別なWasm互換のDockerデスクトップビルド、デモリポジトリなどへのリンクを確認してください。また、 Docker + Wasm のサポートを強化し続ける中で、フィードバックをお待ちしています。
最後に、 今後のミートアップで、専門家や仲間の開発者と一緒にWebAssemblyとマイクロサービスについて詳しく知る機会をお見逃しなく。