ボリュームを残してDocker Desktopを消す

Docker Desktop は単体のアプリではありません。GUI、バックグラウンドの仮想マシン、/usr/local/bin にリンクされた一連のコマンドラインツール、そしていつの間にか数十ギガバイトまで膨らむディスクイメージが一体になったものです。ゴミ箱にドラッグすると最初の部分だけが消え、残りはそのまま残ります。

通常のアンインストールとは逆の問題もあります。公式のアンインストーラを実行すること自体が破壊的であり、後から片付ける段階ではありません。データを守るための順序と、捨ててよい残り物と後で必要になる残り物の見分け方を整理します。

サポートファイルを削除する前に、Docker Desktop の現在の公式アンインストール手順を確認してください。専用アンインストーラやアプリ内コマンドがある場合はそれを先に使い、所有者を確認できる残留物だけを後で扱います。

アンインストールはコンテナ・イメージ・ボリュームを破壊する

Docker は、アンインストールするとコンテナ、イメージ、ボリュームなどのローカルデータが削除されると説明しています。ゴミ箱は経由しません。確認ダイアログがあっても、バックアップや復元の代わりにはなりません。

イメージやコンテナを作り直せるのは、リモートのイメージや必要なビルド元が残っている場合です。ボリュームとコンテナの書き込み層には、Postgres や MySQL のデータなど、唯一のコピーが入っているかもしれません。名前付きボリュームだけでなく、実際の保存先を調べてバックアップしてください。

何より先に、何があるかを一覧します。

docker volume ls

重要なボリュームはアンインストール前にバックアップします。DB は専用のバックアップ・エクスポート機能を優先してください。次のようにファイルを固める場合は、書き込むコンテナを先に停止します。稼働中のコピーは整合性が保証されないため、復元できるかの確認も必要です。

docker run --rm -v <volume>:/from -v "$PWD":/to alpine \
  tar czf /to/<volume>.tgz -C /from .

ビルドしただけで一度も push していないものにも同じことが当てはまります。docker image ls でローカルにあるものが分かります。レジストリになければ、この Mac にしかありません。

空き容量が目的なら、アンインストールは不要かもしれない

Docker のローカルエンジンのデータは、主に仮想ディスクイメージに入っています。空き容量が目的なら Docker は残し、docker system df で内訳を見て不要なものだけ整理できます。ただし prune も取り消せない削除です。対象とディスクイメージの回収方法は、Mac でデータを失わずに Docker を片付ける を確認してください。

Docker を完全に取り除きたい場合は、この先を読んでください。

Docker 純正のアンインストーラを使う

Docker はアンインストーラを同梱しており、アプリを消す以上の処理をします。バックグラウンドサービスをアンロードし、Finder でドラッグしただけでは残るコマンドラインのシンボリックリンクも削除します。

アプリから行う場合は、Docker Desktop を開き、右上の Troubleshoot アイコンを選び、Uninstall を選んで確認します。ターミナルから行う場合は次のとおりです。

/Applications/Docker.app/Contents/MacOS/uninstall

その後、Docker をアプリケーションからゴミ箱へ移します。

Docker が無視してよいと説明しているのは、アンインストール時にコンテナ内の特定のメタデータファイルへアクセスして出る operation not permitted です。同じ文言のエラーすべてを成功扱いにはできません。公式の例とパスを照合し、ほかのパスや処理失敗なら原因を調べてください。

残るものと、その意味

アンインストーラ実行後も、いくつかのフォルダは残ります。Docker が挙げているのは次のふたつです。

~/Library/Group Containers/group.com.docker
~/.docker

これらは同じ種類のものではなく、その違いが本筋です。

~/.docker にはコンテキストやクライアント設定、レジストリ認証または認証情報ヘルパーの設定が入ります。パスワード本体は別の場所で管理されている場合もあります。Docker の再導入や Colima、Rancher Desktop、OrbStack への移行前に、必要な設定をバックアップしてください。削除すると接続設定やログインをやり直す必要があるかもしれません。

~/Library/Containers/com.docker.docker はアプリのコンテナフォルダで、仮想マシンとそのディスクイメージ Docker.raw を保持します。数十ギガバイトがあるのはここで、上で触れた operation not permitted の保護されたフォルダもこれです。~/Library/Group Containers/group.com.docker にあるのは Docker Desktop の設定で、ディスクイメージではありません。コンテナとボリュームが消えた前提で、消す価値があるのはこの 2 つです。

ほかにも Library 配下にキャッシュ、ログ、環境設定、アプリの状態が残る場合があります。関連処理が停止し、設定や調査用のログも不要だと確認してから整理してください。名前に docker が含まれるだけでは、削除の判断材料になりません。

本当に消えたか確認する

確認はふたつです。まず、まだ動いているものがないこと。

pgrep -fl -i docker

次に、コマンドラインツールのリンクが外れていること。

which docker docker-compose

どちらも何も返さないはずです。docker がまだ見つかるなら、Homebrew で別途入れた CLI が残っている可能性が高いです。別パッケージであり、Docker Desktop のアンインストーラでは意図的に残されます。brew list | grep docker で分かります。

残りを一気に確認する近道

手作業でもできますが、どのパスがあるか、どれが自分のデータかをあらかじめ知っている必要があります。ガイドがたいてい飛ばす部分であり、間違えると取り返しがつかない部分でもあります。

Mole は識別できた関連ファイルを種類別にまとめ、場所とサイズを示します。内容を確認し、残したい項目のチェックを外してください。アンインストールで選んだファイルはゴミ箱へ移りますが、Docker の公式アンインストーラが先に削除したデータを復元することはできません。

再インストール後に戻ってくるもの

リモートのイメージや必要なビルド元が揃っていれば、イメージを取得・作成し、コンテナを作り直せます。未 push の自作イメージ、コンテナの書き込み層の変更、ボリュームは唯一のコピーかもしれません。再インストールでは戻らないため、削除前にそれぞれを保存してください。

~/.docker を残せば、コンテキストやクライアント設定の保持に役立ちます。ただしログインを続けられるかは、認証情報の保存先や有効期限次第です。このフォルダを消すと独自の設定も失う可能性があり、再ログインだけで済むとは限りません。

仮想ディスクイメージは空の状態で作り直されます。イメージを再び pull するとまた大きくなるので、アンインストールで解放した数十ギガバイトは、再インストールして通常利用を再開すれば一時的なものにすぎません。長期的にその容量を抑えるのは docker system prune の役割であり、再インストールの繰り返しではありません。