ボリュームを失わずに Docker Desktop をアンインストールする
Docker Desktop は単体のアプリではありません。GUI、バックグラウンドの仮想マシン、/usr/local/bin にリンクされた一連のコマンドラインツール、そしていつの間にか数十ギガバイトまで膨らむディスクイメージが一体になったものです。ゴミ箱にドラッグすると最初の部分だけが消え、残りはそのまま残ります。
通常のアンインストールとは逆の問題もあります。公式のアンインストーラを実行すること自体が破壊的であり、後から片付ける段階ではありません。データを守るための順序と、捨ててよい残り物と後で必要になる残り物の見分け方を整理します。
アンインストールはコンテナ・イメージ・ボリュームを破壊する
Docker ははっきり書いています。Docker Desktop をアンインストールすると、コンテナ、イメージ、ボリューム、そのマシンにだけあるその他の Docker データが破棄されます。取り消しはなく、ゴミ箱に入る段階もありません。二度目の警告もありません。
大半は作り直せます。イメージは再取得でき、コンテナは Dockerfile から再構築できます。例外は名前付きボリュームです。ローカルデータベースがデータを置く場所がそこです。何ヶ月も開発に使ってきた Postgres や MySQL のコンテナは、データはイメージではなくボリュームに置いてあり、そのボリュームも他のものといっしょに削除されます。
何より先に、何があるかを一覧します。
docker volume ls
重要なボリュームがあるなら、アンインストールの前にバックアップします。後では間に合いません。
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 内での prune だけで、目的の空き容量を取り戻しつつツールは入れたままにできることが多く、しかも元に戻しやすいという利点もあります。まずは docker system df で内訳を確認し、Mac でデータを失わずに Docker を片付ける を読んでください。prune と、ディスクファイルが勝手に縮まない理由が書かれています。
Docker を完全に取り除きたい場合は、この先を読んでください。
Docker 純正のアンインストーラを使う
Docker はアンインストーラを同梱しており、アプリを消す以上の処理をします。バックグラウンドサービスをアンロードし、Finder でドラッグしただけでは残るコマンドラインのシンボリックリンクも削除します。
アプリから行う場合は、Docker Desktop を開き、右上の Troubleshoot アイコンを選び、Uninstall を選んで確認します。ターミナルから行う場合は次のとおりです。
/Applications/Docker.app/Contents/MacOS/uninstall
その後、Docker をアプリケーションからゴミ箱へ移します。
アンインストーラが operation not permitted と出しても、Docker のドキュメントでは無視してよいとされています。アンインストール自体は完了しています。このメッセージは、macOS がアプリのコンテナフォルダを保護しているために出るもので、フルディスクアクセスがなければターミナルからは触れません。
残るものと、その意味
アンインストーラ実行後も、いくつかのフォルダは残ります。Docker が挙げているのは次のふたつです。
~/Library/Group Containers/group.com.docker
~/.docker
これらは同じ種類のものではなく、その違いが本筋です。
~/.docker は設定です。コンテキスト、デーモン設定、docker login によるレジストリ認証情報が入ります。あとで Docker を入れ直す場合や、Colima、Rancher Desktop、OrbStack に切り替える場合、残しておきたいフォルダです。削除すると、すべてのレジストリに再度ログインする必要があります。
~/Library/Group Containers/group.com.docker とアプリのコンテナフォルダは、仮想マシンの状態とディスクイメージを保持します。数十ギガバイトがここにあります。コンテナとボリュームが消えた前提で、消す価値があるのはこの部分です。
そのふたつ以外に、Docker はほかの macOS アプリと同様の痕跡を残します。ライブラリ配下のキャッシュ、ログ、環境設定、保存されたアプリケーション状態です。これらは捨てて構いません。名前に docker が付くファイルをすべて消すのではなく、どれがキャッシュでどれが認証情報かを見分けることが大切です。
本当に消えたか確認する
確認はふたつです。まず、まだ動いているものがないこと。
pgrep -fl -i docker
次に、コマンドラインツールのリンクが外れていること。
which docker docker-compose
どちらも何も返さないはずです。docker がまだ見つかるなら、Homebrew で別途入れた CLI が残っている可能性が高いです。別パッケージであり、Docker Desktop のアンインストーラでは意図的に残されます。brew list | grep docker で分かります。
残りを一気に確認する近道
手作業でもできますが、どのパスがあるか、どれが自分のデータかをあらかじめ知っている必要があります。ガイドがたいてい飛ばす部分であり、間違えると取り返しがつかない部分でもあります。
Mole は、何かを消す前にアプリが残したファイルをすべて一覧し、フォルダが実際に何なのかが分かるようグループ化し、サイズを並べて示します。一覧を確認し、残したいもののチェックを外し、消すものはゴミ箱へ入り、いきなり消えることはありません。Docker の場合、取り戻せる容量のほとんどは通常ディスクイメージが占めており、確定前にその数字を見ておくことが、想定外の削除を防ぐ分かれ目になります。
再インストール後に戻ってくるもの
イメージとコンテナは戻ってきます。もともと再現可能だったからです。イメージは再度 pull され、コンテナは Dockerfile から再構築されます。名前付きボリュームは戻りません。ほかのどこにもコピーがない唯一のものであり、だからこそ前のバックアップ手順に意味があります。
~/.docker を残しておけば、レジストリのログイン情報とコンテキストも一緒に戻り、docker login のやり直しを省けます。削除した場合は再度サインインするだけです。かかるのは時間だけで、それ以外の損失はありません。
仮想ディスクイメージは空の状態で作り直されます。イメージを再び pull するとまた大きくなるので、アンインストールで解放した数十ギガバイトは、再インストールして通常利用を再開すれば一時的なものにすぎません。長期的にその容量を抑えるのは docker system prune の役割であり、再インストールの繰り返しではありません。