データを失わずに Mac の Docker を整理する

Docker Desktop は、イメージ、書き込み可能なコンテナレイヤ、ビルドキャッシュ、ボリュームが Linux 仮想ディスク内に置かれるため、数十ギガバイトを使うことがあります。これらの種類は、同じように捨ててよいわけではありません。ビルドキャッシュは通常、作り直せます。一方、データベース用ボリュームは、重要なデータの唯一のコピーであることもあります。安全な整理は、いちばん広い prune コマンドではなく、Docker 自身の内訳から始めます。

Docker の空きが戻ってこない理由

macOS 上の Docker Desktop は Linux VM を動かし、通常は Docker.raw というスパースな仮想ディスクにデータを保存します。Docker の Mac ストレージガイド では、場所・ディスク上限・実際に使っている容量の確認先として Docker Desktop > Settings > Resources > Advanced を案内しています。移動も Finder ではなく、この設定から行ってください。スパースファイルには論理上の最大サイズと、それより小さい物理割り当てがあるため、ls -lh だけでは、いま実際に占めている容量よりずっと大きく見えることがあります。

Docker 自身が何を使っていると考えているか、次で確認します。

docker system df -v

詳細表示では、イメージ、コンテナ、ローカルボリューム、ビルドキャッシュが分かれます。「Reclaimable」は、Docker から見てそのオブジェクトを必要とする現在の参照がない、という意味です。停止中のコンテナ、古いイメージ、ボリュームを明日も使わないことの証明ではありません。prune の前に docker ps -a と docker volume ls も確認してください。

まず狭い範囲から片付ける

必ず Docker の中から回収し、仮想ディスクファイルそのものは削除しないでください。理解できている種類から始めます。

docker builder prune --filter until=168h
docker image prune
docker container prune

最初のコマンドは、条件に合う 7 日より古い未使用のビルドキャッシュを削除します。日数は作業に合わせて調整してください。続く 2 つは、ダングリングイメージと停止中コンテナを削除する前に確認を求めます。prune はゴミ箱を経由せず、取り消せません。停止中コンテナの書き込み層やダングリングイメージにも、再取得できないデータがある場合があります。不要か、復元できるバックアップがあることを確認してから進めます。各操作のあとで docker system df -v を再実行してください。

Docker の pruning ガイド では、docker system prune をより広い一括コマンドとして説明しています。-a を付けると、ダングリングレイヤだけでなく未使用イメージ全体が対象になります。--volumes を付けると、未使用の匿名ボリュームまで広がり、データベースファイルなどの状態が含まれることがあります。docker system prune -a --volumes を、日常の掃除コマンドにしてはいけません。ボリュームを prune する前に、名前と所有関係を確認します。

docker volume ls
docker volume inspect <volume-name>

Compose が作ったボリュームには、通常プロジェクトとサービスのラベルが付いています。所属プロジェクトを特定し、データベースは専用のバックアップ機能でエクスポートしてください。ファイル単位でコピーする場合は先に書き込みを停止し、復元できることを確認してからボリュームを削除します。

ディスクイメージそのものを回収する

Docker.raw を Finder で削除しても、安全に容量を取り戻すことはできません。このファイルは Linux VM のディスク全体なので、Finder や rm で削除すると、空き部分だけでなく中のイメージ、コンテナ、ボリュームがすべて失われ、Docker は次回起動時に空のディスクを作り直します。回収は Docker の中から行います。prune したあとスパースディスクがブロックを返すのを待ち、ディスクイメージの場所と上限は Settings で変更します。表示される大きな数字は多くの場合スパースファイルの論理上の最大値で、実際に使っている物理容量ではありません。すべて回収できると考える前に、実際の割り当てを測ってください。

prune のあと、空きブロックはまず Linux ファイルシステムの中にでき、macOS がスパースディスクからそれを受け取るまでには、必ずしもすぐに反映されません。現行の Docker ドキュメントでは、Docker.raw イメージは通常、ホスト側の回収可能な空きを数秒以内に返すとされています。古い Docker.qcow2 イメージはバックグラウンド処理を使い、数分かかることがあります。ファイルの論理最大値ではなく、実際のディスク使用量を測り直してください。工場出荷時リセットはコンパクションではありません。ローカルのコンテナ、イメージ、ボリューム、設定をすべて破棄します。その完全な損失が意図的で、重要なボリュームデータをすでにエクスポートしている場合にだけ使ってください。

仕組み： なぜファイルは増え、小さくならないのか

Docker Desktop は Linux VM を動かし、Docker.raw はその VM の仮想ディスクです。ゲストが書き込むと増えるスパースファイルで、ゲストが削除しても、macOS へすぐに空きを返すとは限りません。イメージを消すと、VM 内ファイルシステム上ではブロックが空きとしてマークされますが、ホスト側のファイルが小さくなるのは、ゲストが TRIM/discard を発行し、Docker Desktop が discard とコンパクションで回収可能なブロックを返せる場合だけです。タイミングはバージョンとディスクイメージの実装に依存します。だから論理上の整理と、ホスト側の容量変化は別々に測る必要があり、ホストファイルを削除することは Docker 環境全体を破壊するのと同じです。

ディスクマップが役立つ場面

Mole の「分析」画面では、仮想ディスクの場所と実際の使用容量を確認できます。内部オブジェクトの参照関係は Docker の CLI で調べます。macOS 側でどのファイルが大きいかを確認し、Docker 側でその内訳を見ると、削除対象を絞り込めます。

安全な作業順

docker system df -v を実行し、古いプロジェクトと状態を持つボリュームを特定し、唯一のデータをエクスポートし、種類ごとに一つずつ prune します。Docker 内部の合計と macOS の物理容量の両方を再確認します。広い prune フラグは、対象がどう広がるかを確認してから使い、工場出荷時リセットを日常の空き回収の近道にしてはいけません。いちばん早く、かつ安全に効くのは、多くの場合、正体不明のボリュームではなく、古いビルドキャッシュです。