WebAssembly とクラウドコンピューティング

WebAssembly とクラウドコンピューティングについての私の話へようこそ。 私の名前はジョルジェ・ルキッチです。 私はDockerのソフトウェアエンジニアです。 私はランタイムチームで働いているので、Docker、悪魔、CLIに取り組んでいます。 そして昨年から、私はWebAssemblyのものに取り組んできました。 共同講演者のホルヘ・プレンデスは、残念ながら今日はここにいませんが、ランタイムチームにも参加しています。 彼はRustの魔術師であり、 Docker Desktopに最近追加されたすべての新しいランタイムを担当しています。

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

簡単なことから始めましょう。 WebAssembly とは? WebAssemblyとは何か、それがどこから来たのか、そしてなぜ最近これほど興味深いのかを理解することが重要だと思います。 WebAssembly (または Wasm) は、Wasm が私にはちょっと変な言い方なので、私は WebAssembly と言うのが好きです。 したがって、WebAssembly はバイナリバイトコードです。 Javaバイナリバイトコードに、同じ「一度書けばどこでも実行できる」という約束があり、その上に 20 年の経験が加わっていることを想像してみてください。

WebAssembly は、実際には、C コードを JavaScript にコンパイルして、ブラウザー内で C コードを実行できるようにする実験として始まりました。 つまり、名前のウェブ部分の説明はこれで終わりです。 時が経つにつれて、言語に依存しないバイナリバイトコードに進化しました。 今日では、WebAssembly にコンパイルできる言語がたくさんあります。 WebAssembly は言語ではありません。人間が書いたり読んだりするようには設計されていませんが、コンパイラによって設計されているため、WebAssemblyにアセンブリ名があります。 WebAssemblyはWebのために生まれました、そしてそれは私が非常に素晴らしいと思ういくつかの興味深い品質を与えます。

セキュリティ

まず、もちろんセキュリティです。 WebAssembly はブラウザーで実行されます。 また、ブラウザでは、信頼できないサードパーティのコードが多数実行されるため、安全に実行できる必要があります。 また、基本的に、WebAssemblyは基本的に栄光の電卓のようなものです。 数値を非常にうまく処理でき、計算しかできません。

ただし、WebAssembly は外部と対話できません。 これだけでは面白くないので、ランタイムがアセンブリ モジュールに与えることができる関数 (ホスト関数) を追加して、モジュールが外部と通信できるようにする方法があります。 そしてもちろん、ランタイムは、すべてのWebAssemblyランタイムで、モジュールに与えるものを非常に細かく制御して、世界と対話できるようにすることができます。

パフォーマンス

2つ目はパフォーマンスです。 ブラウザはテレビやローエンドの携帯電話のいたるところにあるため、Web上ではパフォーマンスも非常に重要です。 ですから、パフォーマンスは最も重要であり、常に物事をスムーズに実行したいものです。

WebAssembly は非常にコンパクトなバイナリ形式であり、WebAssembly 形式の優れた機能の 1 つは、ダウンロード中に解析とコンパイルを開始できることです。 コンパイルを開始するためにすべてをダウンロードするのを待つ必要はありません。 ほとんどのランタイムはそれをネイティブコードにコンパイルするため、ネイティブに近い速度が得られます。

大きさ

最後に、サイズ、 40メガバイトのWebサイトが好きな人はいません。 WebAssembly バイトコードは非常にコンパクトなバイナリ形式に作られており、非常にうまく圧縮できます。 ですから、これらすべてを見ると、クラウドでもワークロードでも同じようにしたい、と言うことができます。 高速であること、高速な読み込み、安全であることが求められます。 それは、あなたが持っているものをすべて捨てて、ゼロから始める必要があることを意味しますか?

WebAssembly とコンテナ

基本的に問題は、コンテナに対する大きなWebAssemblyの戦いの中にいるのかということです。 そうは思いません。 私はDockerで働いているので、WebAssemblyはコンテナを殺すためにここにいるとは思いません。 考えるべきなのは、コンテナが登場した当時、VMがあったということです。 また、誰もがドラマが大好きですよね? そのため、コンテナはVMを殺すと言われていましたが、今日ではそうではないことがわかります。 現在、VM を使用してコンテナーを実行し、コンテナーを実行する VM の実行に役立つコンテナー ツールを使用することもできます。 そのため、それらは共存し、非常にうまく機能します。 WebAssemblyでも同じだと思います。 インフラストラクチャ部分と配布部分からのすべての知識は、WebAssemblyをより大きくするのに役立ちます。 ですから、WebAssemblyがコンテナに取って代わるとは思いませんが、すべての人に新しいワークフローを提供するでしょう。

WebAssembly はいつ使うのか?

問題は、WebAssemblyをいつ使うべきか、いつコンテナを使うべきか、ということだと思います。 どちらかを選択する際のヒントをいくつか紹介してみました。 WebAssembly は、短命な自己コンテナロジックに適しています。 ですから、実行可能な単純な関数がある場合、特にほとんどのランタイムでは、マーケティングは、ああ、ミリ秒未満の起動時間と言うでしょう。 したがって、クラウド関数がある場合は、WebAssemblyを試して、それが機能するかどうかを確認できます。

WebAssembly の優れた点の 1 つは、プラットフォームに依存しないことです。現在のクラウドには、AMDマシン、Armマシン、そして人気を集めているRISC-Vがあります。 したがって、これらすべてのプラットフォームでコンテナーを実行する場合は、それぞれに対してコンパイルする必要があります。 一方、WebAssembly では、一度コンパイルすれば、これらすべてのプラットフォームで実行できます。 したがって、これは真実ですが、常に真実であるとは限りません。 WebAssemblyで作業している人と話していたところ、浮動小数点数に問題があると言われましたが、ほとんどは本当です。 だから、少なくとも私は彼らが将来それを修正すると思います。

次に、コアのWebAssemblyは非常に安全です。 非常に安全なサンドボックスを備えているため、サードパーティのコードを実行する必要がある場合は、WebAssemblyを使用してください。 たとえば、Shopifyは最近、プラグインをShopify内で実行できるようにし、WebAssemblyモジュールとして実行できるようにしました。 そして、ゲームの名前は何ですか? マイクロソフト、飛行機、フライトシミュレーターとは何ですか? Microsoft Flight SimulatorもWebAssemblyに切り替えて、ゲームの拡張機能を実行しました。 そして、最後に、Spinを見て、試してみたい機能があることがわかったら、それを使ってください。

そして、コンテナ — コンテナはわかっているので、実行時間の長いプロセスがある場合は、コンテナを使用するかもしれません。 前述したように、環境とのやり取りが多い場合、WebAssembly 自体は誰とも通信できないため、多くの異なるサービス、データベース、ファイルシステムと通信する必要がある場合は、WebAssembly よりもコンテナを選択する方がよいでしょう。 WebAssemblyの世界では、彼らはそれに取り組んでいますが、まだそこには到達していないと思います。 そして、あなたがすでにあなたのために働く解決策を持っているなら、それを使い続けてくださいよね?

Docker Desktop での WebAssembly のサポート

これらはすべて、DockerとDocker Desktopにどのように適合しますか? それで、 今年の初めにバルセロナで話をして、そのことについて深く掘り下げました。 基本的に、私たちが行ったのは、 Docker Hubがあり、Dockerを使用してコンテナを実行できるコンテナイメージがあるということです。 そして、私たちが行った作業により、WebAssembly モジュールでも同じことができるようになりました。 WebAssemblyモジュールをWebAssemblyイメージにパッケージ化できると思います。 そして、DockerはそれをプルしてWebAssemblyモジュールを実行できます。 これは、それがどのように機能するかについて過度に単純化された概要のようなものですが、それほど単純ではありません。

では、今日から始めるにはどうすればよいでしょうか? Docker Desktopを使えば、とてもシンプルです。 設定に入ると、有効にする必要がある2つのチェックボックスがあります。 1つはcontainerdを使うため、ストーリー画像を取り込むためのもので、もう1つはWebAssemblyを有効にするためのものです。

ランタイム

WebAssembly を有効にすると、これらのランタイムがすべてダウンロードされます。 これらは、現在のところ、存在し、そのための shim を持つ唯一のランタイムです。 shim は、Docker が使用してイメージを提供し、shim がイメージを実行するプログラムのようなものです。 つまり、基本的には、フェルミオンのスピン、スライトの7つがあり、それらすべてを読むことができます。 そして、先週、私たちは 4をリリースしました。Docker Desktop の24 バージョンでは、Lunatic と Wasm Worker Servers が追加されています。

なぜこれほど多くの異なるランタイムがあるのでしょうか? まず、選択肢があるのはいいことです。 また、それらはすべて実際には同じではありません。 私はそれらを2つに分けることができます。 裸のランタイムがあります — 裸のランタイムは、それをモジュールに与えて実行し、それで終わりです。 つまり、それらはWasmtime、Wasmedge、Wasmerのようなものです。 そして、その反対側には、Spin や Slight など、フレームワーク ランタイムに近いものがあります。 彼らはあなたのWebAssemblyモジュールを実行しますが、その上に何かを追加します。 たとえば、Spin には HTTP トリガーがあります。 そして、最近はAIの良さもあると思います。 それから、スライトもありますが、これも同じです。

Wasm Worker Servers(WWS)はクールなものです。 彼らが行ったのは、言語自体をモジュールにコンパイルしたため、PythonをWebAssemblyにコンパイルしたことです。 そして、そのモジュールにPythonコードを与えて、実行することができます。 お見せします。 なんだかいい感じです。 最後に、Lunaticです。 フレームワークのランタイムリストに入れましたが、その中間のようなものです。 WebAssembly モジュールを実行できますが、並行処理モデルのものが多数追加されました。 試してみて下さい。 あまり遊んでみる時間がありませんでしたが、かっこいいですね。

デモ

いよいよデモです。 大丈夫です。 最初にお見せしたいデモは、シンプルなゴランのデモです。 私がここにあるものを見ると、それは本当に小さなデモです。 複雑にしすぎないようにしたい。 つまり、単純なゴランプログラムです。 私たちは、DockerCon と言います。 そして、現在のOSと現在のアーキテクチャを印刷するだけです。 たとえば、Goでこれを実行できます。 そして、こんにちは、DockerConと書かれています。 そしてもちろん、私はMacのOSを使用しているので、私のOSはDarwinです。 そして、私はM1 CPUを持っているので、それはArm64です。そして、彼らがWebAssemblyのサポートを追加したのはGo 120 だったと思います。 それ以前は、小さなGoを使わなければなりませんでした。 しかし、今日ではGoを使用してプログラムをWebAssemblyにコンパイルすることもできるので、その方法を見てみましょう。

Goでクロスコンパイルする方法は、ビルド時にGOOSとGOARCHを設定し、定義することです。 したがって、この場合のGOOSはwasip1になります。 そしてGOARCHはwasip1になります。 もしかしたら、その逆かもしれません。 そして、あなたは「作れ」と言います。 では、hello.wasm と呼ぶことにします。 大丈夫です。

これでWebAssemblyモジュールができました。 そして、はい、それはうまくいくと思います。 もちろん、これを実行することもできます。 はい。 ここで変わったのは、私のOSはWasip1です。 Wasip1 は Wasi プレビュー 1を意味します。 そして、WasiはWebAssemblyシステムインターフェースであり、WebAssemblyにファイルシステムや環境、その他多くのものから読み取る能力を与えるようなものです。 そして、アーキテクチャはWasmです。 このモジュールでイメージを構築する方法を見てみましょう。 はい。 ナイス。

Wasm イメージの構築

したがって、WebAssembly イメージを構築する方法は、これも方法の 1 つです。 スクラッチイメージは何も含まれていないイメージであるため、最初から開始します。 そこで、何もないところから始めて、Hello WebAssembly モジュールをイメージ内にコピーすることができます。 そうすると、オーケー、エントリポイントは私が中に入れたばかりのモジュールになります。 次に、ビルドするには、wasi / wasmであるプラットフォームを指定し、タグを付ける必要があります。 そして、それはそれです。 しかし、これは本当に面白くありません、なぜなら、WebAssemblyを外部で構築し、それを画像の中に入れるだけだからです。

Dockerを使ってすべてをビルドする方が良いと思います。 そして、そのやり方は、より複雑になりますが、実際にはそれほど複雑ではありません。 golangプログラムをコンパイルするために最初に必要なのは、golangイメージです。 ここのプラットフォームフラグはちょっと新しいです。 つまり、ご覧のとおり、私はwasi / wasmプラットフォーム用に構築しているので、golang wasi / wasmイメージが存在しないため、golangイメージをプルするときに、ターゲットプラットフォームではなく現在のプラットフォーム用のものをプルするようにDockerに指示する必要があります。 だから、あなたはそれにLinuxのgolangイメージを引っ張るように指示し、次にgolangは常にwork / dirを必要とするので、私はwork / dirが必要です。 すべてのコードをコピーし、ターミナルで前に実行したのと同じビルドコマンドをコピーします。 そして最後に、もう一度、ゼロから始めて、モジュールをプルインし、「よし、これが私のエントリーポイントだ」と言います。 それがどのように機能するか見てみましょう。

私はここに私のDockerfileを持っています、そしてそれはあなたがここで見たのと同じものです。 私たちはそれを構築しているだけです。 見てみましょう: "docker build — platform wasi/wasm -t dockercon"。 いいですね、構築します。 DockerCon イメージをビルドしたので、これを実行できるかどうか見てみましょう。 ですから、私が「docker run dockercon」と言うと、ああ、何を言っているのかわからないと言います。 画像をプルしようとしましたが、見つかりませんでした。 このように「docker run」と言うだけで、Dockerは現在のプラットフォームを使用するため、見つかりませんでした。 しかし、私の画像は、ワシプラットフォーム用に作ったので、現在のプラットフォームには存在しません。 だから私は、わかりました、私にdockerconを与えると言う必要がありますが、私はプラットフォームをwasi / wasmにしたいです。

これで画像が見つかりましたが、エラーが発生しました。 このエラーは、DockerがWebAssemblyモジュールの実行方法を知らないことです。 デフォルトでは、Dockerはruncを使用しており、runcはLinuxバイナリの実行方法しか認識していないためです。 あなたがする必要があるのは、このモジュールを実行するときに別のランタイムを使用してほしいと伝えることです。 したがって、「–ランタイム」フラグと画像を使用してそれを行います。 したがって、私の場合、これは "docker run — platform wasi / wasm — runtime io.containerd.wasmtime.v1 dockercon」です。 そして今、これを実行すると、うまくいきます。

WebAssemblyモジュールを含むDockerイメージを構築し、それをDockerに渡して実行に成功しました。 これは一口です。 分かっています;私たちは、io.containerdのように、私が何を知っているのかわからないことを知らなくても、簡単に実行できるようにするさまざまな方法を見つけようとしています。 私たちはより良い方法を見つけようとしています。 私たちはまだそこに到達していません。 そして、あなたが疑問に思っている場合に備えて、これらはすべてあなたが使用できるさまざまなランタイムの名前です。 あなたが持っているすべての7つの異なるシムのすべて。 だから、はい、私はwasmtimeでそれを実行することができます。 Lunaticで走らせてもいいと思います。 ええ、同じです。 また、先ほども言ったように、ランタイムとフレームワークの実行時間があり、例えば、これを Spin で実行しようとしても、Spin にはいくつかの設定ファイルが必要で、Spin イメージが少し異なるため、何も起こりません。 その直後に1つの例を紹介します。

その他の例

ここには他の例があります。 golang は、golang 自体が WebAssembly にコンパイルするために必要なものをすべて備えているため、簡単なものです。 しかし、C言語では、そして他の言語では、よくわかりません。 Rust は WebAssembly にコンパイルするのも簡単だということも知っています。 しかし、C言語では、より複雑です。 その方法は、バイトコードアライアンスがイメージを作成し、CコードをWebAssemblyにコンパイルするために必要なものがすべて含まれているwasi SDKを作成することです。

このイメージがあるとき、WebAssembly にコンパイルする方法を知っている C 言語コンパイラであるこの$CCがあります。 そして、WebAssembly にコンパイルするために必要なすべてのフラグを追加する魔法の C フラグがあります。 そして、あなたはただ、オーケー、私のメインファイルをコンパイルすると言うだけです。 そして、私はWebAssemblyのものが欲しいです。 それでは、それが機能するかどうか見てみましょう。 それはただの単純なHello Worldですよね? したがって、同じになり、「docker build — platform wasi / wasm -t dockercon」になります。 再構築しましょう、そして、はい、私たちは同じ名前を持つことができます。 OK、ビルドします。 そして、今回はwasmedgeでも実行できるかどうか見てみましょう。 うまく行きました！ 時には、それは本当に簡単ではないこともありますが、WebAssemblyにコンパイルするのに役立つツールがたくさんあり、毎日増えています。

これはかわいいですが、もう少し複雑なものを見てみましょう。 私はここに複数のサービスアプリケーションを持っています。 だから、私はこれを本当に速く開きます。 ここには Compose ファイルがあり、アプリケーションには 3 つのサービスが含まれています。 1つは、Nginxイメージを実行するクライアントです。 サーバーはマイクロサービスのようなもので、これはWebAssemblyコンテナまたはワークロードになります。 そして、データベースがあります。 ここで「docker compose up」と言うと、それらすべてを開くことができます。 そして、これが本当に機能するかどうか見てみましょう。 ここに戻ってきたら、localhost 8090、ねえ、私は私のアプリケーションが機能しています。 したがって、ここでは 3 つの異なるコンテナーが実行されています。 データベース、WebAssembly、サーバー、そしてフロントエンドがあります。 それが機能するかどうか見てみましょう。 だから私は注文しなければなりません:ID 12、 13、数量、ロット、金額、税金なし、わからない、 12、配送先住所、家。 そして、注文し、更新すると、そう、フロントエンドはバックエンドと呼ばれるWebAssemblyモジュールであり、それをデータベースに格納しました。

今日から、WebAssembly のものを使い始め、既存のアプリケーション内に置くことができます。 一からやり直す必要はありません。 使い慣れたツールを使用できます。 素晴らしい。

WWSデモ

WWSのデモもお見せします。 このランタイムは、より興味深いものの 1 つです。 さっきも言ったように、WWSはRuby、Python、JavaScript、その他多くの言語をWebAssemblyにコンパイルしていると思います。 このイメージはちょっと違います。 そこには、モジュールを配置するのではなく、ソースコード、Python、およびJSソースコードを配置します。 その後、WWSを使用してランタイムをインストールできます。

ここでは、Pythonランタイムをインストールしています。 JavaScript のものは、すでに WWS にあらかじめバンドルされているため、インストールする方法はありません。 そのため、WWS をコピーし、いくつかの構成ファイルとソース コードをコピーします。 そして、さっそく見てみましょう。 WWS を使用すると、HTTP レスポンダーを作成するようなリスナーがいます。 ですから、ここでは基本的に、誰かが私たちに電話をかけてきたら、私は何かで返事をしたいと言っています。 この場合、HTML を返すだけです。 また、Python の場合も同様で、リクエストを受信するワーカーを定義し、HTML を返します。

これがどのように機能するか見てみましょう。 自分がやったことは本当に面白いと思います。 ああ、私の言語はWebAssemblyにコンパイルされていると言うのは、ちょっと素晴らしいことです。 最初にこれを構築します。 ああ、ダウンロード中です。 少し待って、Wi-Fiが機能することを期待しましょう。 そうですね。 今、私がこれを実行すると。 大丈夫です。 そのため、Python と JS の 2 つのルートをロードしています。 これですべてが読み込まれました。 そして、ポートは 3000、そしてhello JSなどです。 そのため、hello JS ルートを呼び出すと、WebAssembly で実行される JavaScript ファイルが応答します。 そして、私がこんにちはPythonと言うと、応答するPythonスクリプトがあります。 つまり、コードは WebAssembly にコンパイルされませんが、言語は WebAssembly にコンパイルされます。 なぜそうしないのですか?

Fermyonのデモ

さて、最後にもう1つ、Fermyonの友人による小さなデモです。 彼らはRustでWebAssembly用のCMSを作りました。 基本的に、フェルミオンのページに行くと、バーソロミューが反応します。 そこで、私は彼らのスターターを取り、小さな小さなDockerfileを作成しました。 私は、CMS全体のようなBartholomew WebAssemblyを取り上げ、同じエントリポイントを与えています。 前述したように、Spin は単なる WebAssembly ランタイム以上のフレームワークのようなものなので、いくつかの設定が必要です。

それが何を言っているのか、構成で簡単に見てみましょう。 このアプリケーションには 1 つのコンポーネントがあると表示されます。 これはソースであり、IDであり、CMSであるため、そこにいくつかのファイルが必要です。 WebAssemblyモジュールがトリガーされますが、これは任意のルートを意味すると思います。 したがって、これらすべてのファイルが必要です。 そのため、画像内のすべてのファイルとWebAssemblyモジュールをコピーしています。 ここでは、Dockerは使用しません。 Kubernetesを使用してデプロイします。 さて、私はKubernetesの専門家ではありませんが、これを思いつきました。 うまくできます。 そこで、デプロイを作成し、名前を付けます。 これが何をするのかまったくわかりません。 ここでも同じです。 でも、なるほど、これは理解できます。 コンテナが1つ欲しいです。 私はそれに名前を付けています。 構築したイメージを実行するようにします。 これはリビルドしませんが、これはすでにHubにあるので、自分のマシンで使用することもできます。 そして、これはあなたが必要とする別のものです。

Kubernetes内でWebAssemblyモジュールを実行する場合は、特別なランタイムクラスが必要です。 Dockerの場合と同じで、ああ、これはランタイムだから、これを使ってほしい。 ここでは、このコンテナーには、このランタイムが必要であることを伝えています。 そして、ランタイムをインストールする方法は、ランタイムクラスの種類を持つ別のYAMLファイルだと思います。 そして、誰かがwasmtimeスピンを要求したら、ハンドラースピンを使ってほしいと言っています。 何が起こっているのかは理解できると思います。 基本的に、ハンドラーの名前は spin です。 そして、containerdはio.containerd.spin.vを探すと思います1 実行中。 それがcontainerdの仕組みだと思いますが、繰り返しになりますが、私はKubernetesの専門家ではありません。

では、中に入ってみましょう。 始める前に、私はクラスターを立ち上げました。 ローカルで 1 つのクラスターを実行していますが、事前設定も必要です。 あなたが物事をテストしたいなら、これは人々が作成した素晴らしいツールです。 Kubernetesクラスタ内に必要なものをすべてインストールして、WebAssemblyを実行できるようにします。 ほとんどどこでも使用できます。

そのため、Kindクラスタがすでに実行されており、kwasm operatorをインストールする必要があります。 したがって、ここでデプロイを適用できます。 さて、すでに追加したので変更はありません。 ここにデプロイがあることがわかります。 私たちの「バート」、そして私たちがテストする準備ができているものがあります。 通常、Kubernetesでは、サービスやロードバランサーも必要だと思いますが、何かはわかりませんが、この「ポートフォワード」を使用します。 ええ、魔法のコマンドラインで、わかりました、展開bartのポートフォワードをしてほしい、そしてバーソロミューがポート8080で私のローカルホストをリッスンしているポート80を展開してほしいのです。ポートフォワーディングを開始し、WebAssembly CMSができました。 ありがとうございます。 私たちはKubernetesで実行しています。 さて、もうすぐです。

参加しませんか

だから、私たちに参加してください。 Docker Desktop 内にないランタイムが見つかり、それが必要な場合は、ぜひご相談ください。 WebAssembly に関する機能が必要な場合は、GitHub に Docker ロードマップ リポジトリがあり、そこで問題を追加できます。 また、マイクロソフトやインテルなどと共同で取り組んでいる runwasi プロジェクトもあります。 runwasi プロジェクトは、実際には、すべてのランタイムが shim を作成して使用できるようにするためのプロジェクトです。 ですから、私たちは積極的に取り組み、すべての人を支援しています。 また、SlackのコミュニティにはWebAssemblyチャンネルがあります。 挨拶に来てください。

質疑応答

皆さん、私の話を聞いてくれてありがとう。 質疑応答の時間を設けます。

デモをありがとうございました。 Dockerで私が気に入っていることの1つは、レイヤーです。 巨大なプロジェクトがあり、HTML ファイルを 1 行だけ変更します。 Docker イメージ全体がビルドされるわけではありません。 レイヤーのみを使用します。 ここでは、アプリケーションを構築するたびにバイナリを構築しているようです。 そのバイナリは何らかの形でレイヤーを使用するのでしょうか、それともアプリケーション全体を構築するたびに常に巨大なバイナリになるのでしょうか?

いい質問ですね。 それは私がまったく話さなかったことです。 これを見ると、各コピーコマンドでレイヤーが作成され、最後のレイヤーにのみモジュールがあります。 したがって、今日のWebAssemblyイメージの作成方法は、通常のコンテナイメージと同じです。 しかし、何か別のことに取り組んでいる人もいます。 将来的には、おそらく今年か来年、WebAssemblyコンポーネントが登場すると思います。

私たちは、これらすべてをパッケージ化するさまざまな方法を考えています。 もしかしたら、WebAssemblyコンポーネント用のレイヤーを用意する代わりに、それらを脇に置いて、実際のコードのように別のレイヤーにするかもしれません。 はい、イメージのルートファイルシステムから完全に削除できるように、特別なレイヤーです。 また、WebAssembly用にファイルシステムを仮想化できるものがたくさんあることもわかりました。 そのため、ルートファイルシステムも必要ありません。 また、VFSのようなものを提供する別のコンポーネントを実行することもできます。 しかし、それはすべてかなり新しく、実験的なもので、私たちはそれに取り組んでいます。 しかし、今日では、レイヤーについて知っているのと同じことがあり、WebAssemblyでも機能します。

C言語のような安全でない言語をWebAssemblyにコンパイルすることで、WebAssemblyのセキュリティ層が抱える安全上の問題のいくつかは解決されるのでしょうか? ですから、WebAssemblyはサンドボックスですからね。 それはただの電卓です。 それ自体では何もしません。 しかし、もちろん、ファイルシステムやネットワークと通信するコードがある場合は、いくつかの問題がある可能性があります。 しかし、素晴らしいのは、あれやこれやにアクセスできるようにしたい、と本当に細かく言えることです。 しかし、もしあなたがWebAssemblyしか持っていなくて、私にはわかりませんが、いくつかのコードをクランチするのであれば、今よりもずっと安全だと思います。

さらに詳しく

• Wasm ワークロード
• Docker デスクトップの最新リリースを入手します。
• 次の予定に投票しましょう! 公開ロードマップをご覧ください。
• 質問がありますか? Docker コミュニティがお手伝いします。
• Docker は初めてですか? さっそく始めましょう。
• Docker Newsletter を購読してください。