Docker DesktopのWasmワークロード - 仕組みと非推奨化後の判断

Docker Desktopには、Linuxコンテナと並べてWebAssembly（Wasm）ワークロードを実行するベータ機能があります。Docker CLIやComposeに近い操作でWasmモジュールを起動できる仕組みですが、2026年7月現在、Docker公式ドキュメントはこの機能を非推奨とし、将来のDocker Desktopで削除すると案内しています。

現在の結論

記事情報: 2025年12月13日初出。Docker公式資料を2026年7月25日に再確認し、非推奨化を反映しました。

新規の本番システムで「Docker DesktopのWasm機能を長期利用する」前提の設計は勧められません。学習や既存構成の確認には利用できますが、削除予定であることを含めて検証してください。

ここで非推奨なのはWebAssemblyそのものではなく、Docker DesktopがWasmランタイムをまとめて提供する当該機能です。Wasmをサーバーで使う選択肢を検討する場合は、利用するWasmランタイムやオーケストレーション基盤の公式情報を別に確認します。

どのように動くのか

通常のLinuxコンテナは、OCIイメージ内のLinux向け実行ファイルをruncなどのランタイムで動かします。Docker DesktopのWasm機能では、containerdがWasm用shimを経由してWasmtime、WasmEdge、Spinなどのランタイムを選び、Wasmモジュールを実行します。

docker CLI / Compose
        |
    containerd
      /     \
   runc    runwasi系shim
    |          |
Linux実行物   Wasmモジュール

同じCLIから起動できても、LinuxコンテナとWasmは同じ実行形式ではありません。既存のLinuxバイナリをそのままWasmランタイムへ渡すことはできず、対象のWASI環境に合わせてビルドする必要があります。

--runtimeと--platform

Docker公式の例では、実行時にWasm用ランタイムとプラットフォームを明示します。

docker run --rm \
  --runtime=io.containerd.wasmedge.v1 \
  --platform=wasi/wasm \
  secondstate/rust-example-hello

--runtimeは利用するcontainerd shimを、--platform=wasi/wasmはイメージの対象プラットフォームを示します。利用できるランタイム名は、Docker Desktopの版とインストール状態によって異なります。古い記事のコマンドをそのままコピーせず、現在の設定画面と公式ページを確認してください。

有効化に必要な条件

公式手順では、Docker Desktopでcontainerd image storeを使い、開発中機能からWasmを有効にします。Docker Desktop 4.34以降ではcontainerd image storeが既定になっていますが、既存環境で切り替えている場合があります。

image storeを切り替えると、反対側のstoreにある既存イメージやコンテナが画面上で見えなくなります。削除されたわけではなく、元のstoreへ戻すと再び見えますが、作業前に現在の設定を記録しておくと混乱を避けられます。

Wasm機能を有効化すると、Docker Desktopが複数のランタイムをダウンロードします。組織管理PCでは、ソフトウェア導入ポリシーやネットワーク制限も確認してください。

Composeで混在させる

Wasmサービスと通常のLinuxコンテナを同じComposeファイルに書けることが、この機能の主な狙いでした。概念的には次のような構成です。

services:
  wasm-app:
    image: example/wasm-app
    platform: wasi/wasm
    runtime: io.containerd.wasmedge.v1

  database:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: development-only

実際のランタイム、ポート公開、ネットワーク対応はWasmアプリ側の方式によって変わります。すべてのWASIモジュールがHTTPサーバーとして同じように起動するわけではありません。たとえばSpinのアプリとWasmEdge向けモジュールでは、必要なruntime指定や起動モデルが異なります。

また公式ページには、Composeの終了処理が正常に完了しない場合があるなどの既知の問題が記載されています。検証環境で停止・再起動・後片付けまで試してください。

Linuxコンテナとの選び分け

Wasmは移植可能なバイナリ形式と、能力を限定した実行モデルを利用できる点が特徴です。一方で、一般的なサーバーアプリが期待するOS機能をすべて備えるわけではありません。

Wasmを検討しやすい処理

• 入出力が明確で、小さく分離された関数
• 信頼境界を分けたいプラグイン処理
• 対応ランタイムが明確なエッジ処理
• Wasm向けSDKやコンポーネントとして設計する新規処理

Linuxコンテナを維持しやすい処理

• OSコマンドやLinux固有APIへ依存する既存アプリ
• ネイティブライブラリやデバイスアクセスを多用する処理
• シェルスクリプトを含む既存運用をそのまま移したい場合
• Docker Desktop以外も含めた運用経路がすでに確立している場合

Wasmの起動時間やイメージサイズが小さくなる可能性はありますが、結果は言語、ランタイム、処理、計測条件に依存します。「Wasmだから常に速い」とは判断せず、実際のワークロードで測ります。

WASIと互換性を理解する

WASIは、Wasmコードからファイルやネットワークなど外部機能へアクセスするためのインターフェース群です。WASI Preview 1向けに作ったモジュール、Preview 2のコンポーネント、特定ランタイムの独自拡張は同一ではありません。

検証時には少なくとも次を記録します。

• コンパイル対象（例: WASI Preview 1か、componentか）
• 使用した言語とツールチェーンのバージョン
• Docker Desktopとcontainerd shimのバージョン
• ファイル、ネットワーク、環境変数の必要権限
• macOS、Windows、Linuxでの差

「Wasmファイルが生成できた」だけでは、目的のランタイムで必要なI/Oが使えるとは限りません。まずHello World、次にファイル入力、最後にネットワークというように、能力を1つずつ確認します。

よくあるエラー

Unknown runtime specified

指定したshimが導入されていないか、containerd image storeが無効な可能性があります。Docker DesktopのWasm設定と、公式資料にある現在のruntime名を確認します。

failed to resolve runtime path

使用中のDocker Desktopが対象runtimeを含まない場合や、runtimeのインストールが完了していない場合に起こります。更新だけでなく、非推奨機能を組織ポリシーが無効化していないかも確認してください。

Linux向けイメージをWasmとして実行できない

--platform=wasi/wasmを付けても、LinuxバイナリがWasmへ変換されるわけではありません。Wasm向け成果物とOCIイメージ設定を用意する必要があります。

これから採用する場合

学習目的なら、Docker公式のサンプルを一度動かし、runtimeとplatformが通常のコンテナとどう違うか観察する価値があります。ただし、長期運用を見据えた評価ではDocker Desktopの機能削除後を先に考えます。

1. なぜLinuxコンテナではなくWasmが必要かを文章化する
2. Docker Desktopに依存しない実行候補を調べる
3. 必要なWASI機能が対象ランタイムで安定しているか確認する
4. ローカル、CI、本番で同じ成果物を動かす試験を行う
5. ランタイム更新と脆弱性対応の担当を決める

このニュースの要点は「DockerがコンテナをWasmへ置き換えた」ことではありません。Dockerとcontainerdの操作体系へWasmを接続する試みが提供された一方、Docker Desktopの該当機能は現在非推奨です。新規採用では、そのライフサイクルを最優先で判断してください。

参考リソース

• Docker Desktop: Wasm workloads
• Docker Desktop: containerd image store
• Docker Engine: Alternative container runtimes
• containerd/runwasi

×

PR

×

PR