WSLコンテナーで利用するストレージは、Dockerコンテナに準拠しているが、実装などに違いがある。今回は、WSLコンテナーのストレージについて解説する。なお、Dockerでは、コンテナを作成するための雛形を「イメージ」と呼び、イメージから実際にメモリ上に作られた実行環境を「コンテナ」と呼ぶ。WSLコンテナーの解説でもこの用語定義に従うことにする。
WSLコンテナーにおけるストレージは4種類
Docker/WSLコンテナで使うストレージだが、基本的には4種類だ。
コンテナストレージとは、コンテナ実行環境を構成しているストレージのこと。通常の環境でいえば、OSがインストールされているストレージである。ここは、普通にアプリケーションでアクセスが可能だが、コンテナが消えてしまうと同時に消えてしまう。
このコンテナストレージは、ユーザーのホームディレクトの「C:\Users\<ユーザー名>\Appdata\Local\wslc\」以下にある「storage.vhdx」だと思われる。このVHDXファイルには、パーティションテーブルがなく、確認ができなかった。
これに対して「ボリューム」「バインド」の2つのストレージは、ファイルをコンテナ外に保存するため、コンテナが消えても、ファイルが残る。
ボリュームは、wslコンテナエンジン側で管理している場所にデータを記録し、これをボリュームの名前でアクセスする。ボリュームは、その名前を知っているなら、複数のコンテナからボリュームを共有できる。
また、ボリュームは、前記のwslcフォルダ以下にあるvolumesフォルダにあり、ボリューム作成時につけた名前がそのままファイル名になったvhdxファイルである。実行時にすでに作成したボリュームをアクセスするには
wslc container run -it --mount type=volume,source=my-volume,target=/volume debian bash
とする。これでvolumeが作成されて、bashが起動するので、/volume(ターゲット)に適当なファイルを書き込んでCtrl-P、Ctrl-Qで抜ける。このときコンテナは実行中のままになる。
再度同じコマンドで別のコンテナを起動して/volumeディレクトリを見れば、前に起動したコンテナで書き込んだファイルが見えるはずである。
「バインド」は、ホストOS側のディレクトリを保存先としてコンテナに接続するもの。ホスト側から簡単にコンテナ側のファイルにアクセスが可能になるのがメリットでもあり、そこがデメリットでもある。
そもそもコンテナを使うのは、ホスト側と切り離した独立した環境を作るためでもある。なのにホスト側のディレクトリを使うことでホストとの関係ができてしまう。また、もしこれをイメージ化したとき、他の環境に持っていっても、ホスト側で必要なディレクトリを用意する必要があり、コンテナ自体の独立性が失われる。
バインドは、wslコンテナーでは、wslのホストファイルの参照機能を使う。これは、wslc.exe runコマンドのマウントオプションで、type=bindとして、source=<Win32側ディレクトリ>とtarget=<バインド先ディレクトリ>を指定する。たとえばdebianイメージで、win32側のc:\tempをコンテナの/appにバインドでマウントするには、
wslc container run --mount type=bind,source=c:/temp,target=/app debian ls /app
とする。この場合、c:/tempのファイル、フォルダが表示されればコンテナは作成されて、コマンド(ls app)が実行されている。コンテナはコマンドの実行後、停止する。
「tmpfs」は、特殊なデバイスドライバを作り、メモリの一部をディレクトリとして実現するもの。読み書きが高速で、テンポラリファイルへのアクセス速度がシステムを律速するような場合に効果がある。反面、ホスト側のメモリを圧迫してしまう。また、wslコンテナの場合、コンテナをホストする仮想環境のメモリを圧迫し、場合によっては、スワップの発生などで、コンテナ内のソフトウェアの実行効率に影響が出てしまう。
wslc.exeで「--tmpfs」オプションを使う場合、「--tmpfs <マウント先>」とする必要がある。Dockerでは、「--tmpfsは単なるフラグでtmpfsを有効にするだけのものだったが、wslコンテナーでは、マウント先の指定が必須のようである。
コンテナ内ファイルに書き込みをし、そのほか、リポジトリからプログラムをインストールした状態のコンテナを作成したい場合、Dockerでは、コンテナからイメージを作成することで、イメージを作ることができる。しかし、現在のwslc.exeには、そのためのcommitサブコマンドがない。イメージを作成するには、Dockerfile形式のファイルをbuildサブコマンドでコンパイルする必要がある。
wslコンテナーは、Dockerを手本にはしているが、Dockerとまったく同じではない。基本的な機能はあるが、まだ、Dockerのほうが機能が多く、すぐにでも乗り換えるというものでもないだろう。次回は、WSLコンテナーのネットワーク関連の機能を見ていくことにする。
本記事はアフィリエイトプログラムによる収益を得ている場合があります

この連載の記事
-
第549回
PC
安定版に進化したWSLコンテナーの仕組み -
第548回
PC
Windows 11 Ver.26H2の配布が開始 すでに5回目のメジャーアップデートで「次」も気になる頃合い!? -
第547回
PC
Windows 11におけるファイルとフォルダの削除の仕組みについて -
第546回
PC
Windows 11でBluetoothオーディオ共有(Auracast)を試してみる -
第545回
PC
PowerShellにおけるwinget -
第544回
PC
Windows 11 Ver.26H2プレビュー公開 さらにその次のWindowsも少し見えてきた -
第543回
PC
「WMIC」が消滅 コマンドが消える「WMI」とはそもそも何? -
第542回
PC
PowerToysの最新版では、今使っているアプリの複数ウィンドウをショートカットで切り替えられる便利機能が追加 -
第541回
PC
AIを組み込んだWindowsターミナル「Intelligent Terminal」をインストールして試してみる -
第540回
PC
Windows 11に付属の新しいOutlookでアカウント設定をする - この連載の一覧へ












