# Windows上のDockerとWSLのディスク容量: レイヤー、ボリューム、安全な整理 Dockerはクリーンアップのあと大きな削減を報告しても、Cドライブがすぐ同じ容量を得るとは限りません。測っている層を特定します。Dockerのリソースはその環境の中にあり、Linuxのファイルシステムは仮想ディスクの中にあり得て、Windowsはそのディスクをファイルとして見ます。環境の中で再利用できる空きと、ホストで解放される容量は違います。 ## 先に環境を特定する 今のDockerコンテキストとストレージの内訳を見ます。次のコマンドは、リソースを消さずに情報を読みます。 ```powershell docker context show docker system df -v docker ps -a docker volume ls wsl --list --verbose ``` リモートのDocker接続は、ローカルのCドライブの使用ではなく、リモートのリソースを報告します。`DOCKER_HOST`や`DOCKER_CONTEXT`が設定されていないかも確認します。環境変数は接続先を上書きでき、[コンテキストのドキュメント](https://docs.docker.com/engine/manage-resources/contexts/)に説明があります。WSLの一覧は、ローカルのディストリビューションとバージョンを示します。[DockerのWSLバックエンドのドキュメント](https://docs.docker.com/desktop/features/wsl/)は、データの配置がインストール履歴に依存すると説明しています。すべてのPCが同じDockerデータの分布だと思い込まないでください。 ## 共有されるイメージレイヤーが計算を変える [Dockerのディスク使用量のリファレンス](https://docs.docker.com/reference/cli/docker/system/df/)は、共有サイズと固有サイズを分けます。イメージはレイヤーを再利用できるので、1つ外しても表示された合計が空くとは限りません。回収可能は、今の参照関係での候補であり、中身が不要だという保証ではありません。 | リソース | 典型的な中身 | 削除前の確認 | | --- | --- | --- | | イメージ | ランタイムとアプリケーションのレイヤー | プルまたは再ビルドできるか。ほかのコンテナが使っているか | | コンテナ | インスタンスと書き込み可能レイヤー | 停止したコンテナに、書き出していない内容があるか | | ビルドキャッシュ | 再利用できるビルド結果 | 次のビルドが必要なものをダウンロードして再計算できるか | | ボリューム | 永続的なデータベースやアップロードされたファイル | どのプロジェクトのものか。回復は確認済みか | 仮想の例では、2つの2GBイメージが1.5GBを共有します。1つ外しても2GB戻るとは限りません。今のコンテナから参照されていないボリュームにも、今止めたデータベースが入っていることがあります。 ## 問題がビルドキャッシュなら、そこを対象にする ソース、依存関係の入手元、ビルド設定がまだ使えることを確認します。キャッシュされた結果の再ビルドを受け入れるなら、[Dockerのbuilder pruneコマンド](https://docs.docker.com/reference/cli/docker/builder/prune/)がビルドキャッシュを対象にします。次のコマンドは対象のキャッシュを削除します。受け入れる前に確認を読み、対話の確認は有効のままにします。 ```powershell docker builder prune ``` 範囲は`docker system prune`より狭いです。あちらは停止したコンテナ、選ばれたイメージ、ネットワークも対象にします。[system pruneの追加オプション](https://docs.docker.com/reference/cli/docker/system/prune/)は、削除をさらに広げます。すべてのプロジェクトに万能のコマンドを使わないでください。ビルダーが複数あるときは、選ばれているビルダーを特定します。1つの環境を整理しても、ほかが処理された証明にはなりません。 ## 永続データは別にバックアップする データベースはそれぞれのツールで書き出し、隔離した環境で復元を確認します。[Dockerのバックアップのガイド](https://docs.docker.com/desktop/settings-and-maintenance/backup-and-restore/)は、イメージのデータとボリュームのデータを分けています。イメージを保存またはコミットしても、接続されたボリューム内のファイルは含まれません。Composeファイルは構成を記述するもので、データベースの内容を保持しません。 Docker Desktopの仮想ディスク全体をバックアップするなら、文書化されたシャットダウン手順に従い、バックエンドと設定されたデータの場所を特定してから、正しいファイルをコピーします。変化中のVHDXは安定したバックアップではありません。個人のWSLディストリビューションは、[WSLのエクスポートの案内](https://learn.microsoft.com/en-us/windows/wsl/basic-commands)を使って別にバックアップします。ディストリビューションの登録解除はそのデータを消します。日常の容量整理の手順ではありません。
Dockerのリソースは残し方が違う
参照されていないボリュームにも価値のあるデータが残り得ます。共有されるイメージレイヤーも、1回の削除で解放される量を制限します。
## Linuxの層とWindowsの層を比べる 自分のディストリビューションの中では、`df -h /`がルートファイルシステムの使用量を報告し、`du -h --max-depth=1 /home`がユーザーディレクトリの増加を探す助けになります。2つ目はシステム全体の合計ではなく、権限とほかのディレクトリがその範囲を制限します。マウントされたドライブをすべて歩くのではなく、大きいと分かっているディレクトリから始めます。 [MicrosoftのWSLストレージのガイド](https://learn.microsoft.com/en-us/windows/wsl/disk-space)は、動的なVHDの増加を説明しています。Linuxの容量の上限は、Windowsが割り当てた使用量ではありません。削除は内部の再利用可能な空きを増やしても、外側のファイルがすぐ縮むとは限りません。ホスト側で回収するときは、今のWSLとDockerのバージョンと、サポートされた手順を確認します。AppDataの仮想ディスクを削除または移動しないでください。容量上限を増やすことを、Cドライブを空けることと取り違えないでください。ホストのファイルを回収するには、先にディストリビューションの中で空きを作り、それからMicrosoftのWSLディスク容量のガイドとDocker Desktop自身のディスクイメージ設定に従って仮想ディスクを圧縮します。正確なコマンドはWSLのバージョンとDockerのバックエンドに依存するので、1つのコマンドをコピーせず、バージョン固有の手順を使います。 クリーンアップのあと、`docker system df -v`を繰り返し、残すサービスを動かし、データベースのレコードを見て、元のビルドを完了します。Docker、Linux、Windowsの読み取りは分けて確認します。Moleの分析ページは大きなファイルを探せます。リソースと仮想ディスクの管理は、持ち主のツールの仕事です。普通のパッケージキャッシュは[開発キャッシュのガイド](/ja/windows/blog/windows-developer-caches)を見てください。 Canonical: https://mole.fit/ja/windows/blog/docker-wsl-disk-space-windows