rancher desktopの覚書
はじめに
Docker Desktopは、ライセンスの問題で現場で使えないことがあるため
Docker Desktopを普段使いにするのは、避けたい
Docker Engine直は、トラブったときに、GUI操作できず、マニアックなコマンド調べるのが
メンドイから、好んで使うのは、やめたい
Rancher Desktopならば、ライセンス問題なく、Docker Desktopに近い使い方できるから
Rancher Desktop使ってるけれど、
Rancher Desktop特有の覚書しておかなければならないことが、いくつかあるし
そんなん、覚えられないから、ここに書いておくことにした。
覚書その1
Docker Composeを使いたかったら、Container Engineは、「 dockerd 」で使う
覚書その2
-
k8sを動かすには、CRI v1 に対応したコンテナランタイムが必要で、rancher desktopのContainer Engineについて、containerdはこれを満たすが、dockerdはこれを満たさない（dockerdでk8sを動かすには cri-dockerd のような橋渡しが別途必要）
-
ローカルPCでは、dockerdが使いたい（他の用途でもDocker Composeを使うから）
-
この状態で、ローカルでk8sを動かしたい
-
dockerdの環境でも、minikubeを使うと、minikubeが作るクラスタ（ノード）内部でcontainerdを使う構成にできるから、それを通じてローカルでk8sを動かせる
覚書その3
Rancher Desktopを起動すると、80番のポートをhost-switchのプロセスがつかむ
だから、なにかのアプリで80番ポート前提にしてる場合は、そちらを別のポートに変える手立てを
考えること。
このRancher Desktopのhost-switchのプロセスを80以外にするとトラブル多いからやめたほうが
いいらしい。
PowerShell 7.5.4
PS C:\Users\myuser> netstat -a -n -o | findstr /R /C:":80 .*LISTENING"
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 13364
TCP [::]:80 [::]:0 LISTENING 13364
PS C:\Users\myuser>
PS C:\Users\myuser> Get-Process -Id 13364 | Select-Object Id,ProcessName,Path
Id ProcessName Path
-- ----------- ----
13364 host-switch C:\Program Files\Rancher Desktop\resources\resources\win32\internal\host-switch.exe
PS C:\Users\myuser>
バインドマウントと、名前付きボリュームの区別に関する知識
これは、Rancher Desktopだけの話でなく Docker Compose全般の話
バインドマウントと、名前付きボリュームの区別に関する知識
- volumes: の SOURCE:TARGET で、SOURCE が ホストのパス（例：/... や ./... や ../...）なら bind mount。
- SOURCE が パスではない単なる名前なら 名前付きボリューム。
- TARGET だけ（source省略）なら 匿名ボリューム（source omitted）。
名前付きボリュームは、
docker compose down
や、
sail down
のときに、-v をつけなければ、残る
docker compose down -v
sail down -v
だと消える
しかし、いろいろ複数のプロジェクトを並行してやってるときに、
環境構築でトラブった時など、一回、全部、消すとかするでしょう
docker system prune -a --volumes みたいに --volumes を付ける掃除や、
GUIの「全削除」系をやると ボリュームは消え得る。
一方、バインドマウント先のホストディレクトリは Docker の prune では消えない
そして create-testing-database.sh については、MySQL公式の仕様として
データディレクトリ（/var/lib/mysql）に既存DBがある場合、
初期化系は実行されない（既存DBは触らない）
つまり、バインドマウントでデータが残ってる限り、
初回だけ作られて以後は残る
という特性があるため
バインドマウントでmysqlのデータを永続化しとくほうが環境的に安心である
例として
volumes:
- 'sail-mysql:/var/lib/mysql'
- './vendor/laravel/sail/database/mysql/create-testing-database.sh:/docker-entrypoint-initdb.d/10-create-testing-database.sh'
となってるものを
volumes:
- './DB/volume:/var/lib/mysql'
- './vendor/laravel/sail/database/mysql/create-testing-database.sh:/docker-entrypoint-initdb.d/10-create-testing-database.sh'
に書き換えるような感じ
＜＜他、見つかり次第、ここに追加することにした。＞＞＞
Rancher Desktopのデータを綺麗に全部削除して入れなおす方法
2026/05/10 時点で、WSL2上の開発環境を Ubuntu-24.04-my から Ubuntu-26.04-my へ移行している。
Ubuntu-24.04-my 側で必要だったプロジェクトデータは、フォルダごと tar で保存し、それを Ubuntu-26.04-my 側に展開した。
また、~/.bashrc の記載内容など、必要な設定も Ubuntu-26.04-my 側に反映した。
そのうえで、大容量の外付けハードディスクに Ubuntu-24.04-my のバックアップを取った後、PowerShell で次のコマンドを実行した。
wsl --unregister Ubuntu-24.04-my
これにより、Ubuntu-24.04-my の WSL ディストリビューションは登録解除され、そのディストリビューションに紐づく ext4.vhdx も削除された。
この段階で、PC本体のハードディスク領域は大きく空いた。
ただし、ここで注意が必要なのは、Rancher Desktop のデータは Ubuntu-24.04-my の ext4.vhdx とは別に、Rancher Desktop 自身が作る WSL ディストリビューション側にも残るという点である。
Rancher Desktop は、Windows上で WSL2 を使う場合、主に次のような WSL ディストリビューションを使う。
rancher-desktop
rancher-desktop-data
このうち、rancher-desktop-data は、コンテナイメージなどの保存に使われる Rancher Desktop 側の永続データ領域である。
自分の環境では、次の場所に Rancher Desktop 側の ext4.vhdx があった。
C:\Users\<Windowsユーザー名>\AppData\Local\rancher-desktop\distro-data\ext4.vhdx
このファイルが約23GBあった。
つまり、Ubuntu-24.04-my を削除しても、Rancher Desktop 側のコンテナイメージ、コンテナ、Docker volume、Kubernetes 関連データなどは、Rancher Desktop 側のデータとして残っている。
今回の移行では、プロジェクトフォルダ自体は Ubuntu-26.04-my に tar で移行済みであり、その中に docker-compose.yml や Dockerfile も含まれている。
そのため、Rancher Desktop 側に残っている古いコンテナ実行環境を引き継ぐのではなく、一旦すべて削除して、Ubuntu-26.04-my 側で新しく作り直すことにした。
Ubuntu-26.04-my 側で、プロジェクトフォルダに移動して、必要に応じて次のように実行すれば、Docker環境は再構築できる。
docker compose build --no-cache
docker compose up -d
ただし、Rancher Desktop 側の named volume にしか存在しないDBデータやアップロードファイルがある場合、それらは削除対象になる。
自分の場合、必要なプロジェクトファイルは Ubuntu-26.04-my 側に移行済みであり、Rancher Desktop側の古いコンテナ、イメージ、volume、Kubernetesデータを残す必要はないため、Rancher Desktopをクリーンに入れ直す。
先に理解しておくこと
Rancher Desktopを綺麗に削除する目的で、単にアプリだけをアンインストールするのは不十分である。
Rancher Desktop公式FAQでは、クリーンアンインストールを行う場合、先に Factory Reset を実行してからアプリをアンインストールする、という手順になっている。
また、Rancher Desktop公式ドキュメントでは、Factory Reset はクラスタとRancher Desktopの設定を削除し、初回セットアップからやり直す状態にする操作として説明されている。
そのため、今回は次の順番で進める。
1. Rancher DesktopでFactory Resetする
2. Factory Resetが完了したかを確認し、念のため公式手順どおりに、wsl --shutdown を行う
3. Rancher Desktopをアンインストールする
4. Rancher Desktopを再インストールする
5. Ubuntu-26.04-my 側でWSL Integrationを有効にする
6. Ubuntu-26.04-my 側でDocker環境を作り直す
1. Rancher DesktopでFactory Resetする
Rancher Desktopを起動する。
左側メニューで Troubleshooting を開く。
Factory Reset のところにある Reset ボタンを押す。
確認画面が表示されるので、Keep cached Kubernetes images のチェックは外した状態にする。
その状態で、Factory Reset を押す。
これで Kubernetes が停止し、Rancher Desktop が終了する。
今回は、古いキャッシュも含めて綺麗に消したいため、Keep cached Kubernetes images はチェックしない。
2. Factory Resetが完了したかを確認し、念のため公式手順どおりに、wsl --shutdown を行う
Rancher Desktopで Factory Reset を実行すると、Rancher Desktopの画面が閉じる。
ここで最初に不安になるのは、「本当にFactory Resetが完了したのか」「裏でまだ処理が動いているのではないか」という点である。
ただし、Rancher Desktop公式ドキュメントでは、Factory Resetの手順として、最後に Factory Reset をクリックすると、Kubernetesが停止し、Rancher Desktopが閉じると説明されている。
つまり、Factory Reset後にRancher Desktopの画面が閉じること自体は、公式手順どおりの動作である。
とはいえ、画面が閉じただけでは、PC上で本当にRancher Desktopのデータが削除されたのかは分からない。
そこで、Rancher Desktopをアンインストールする前に、PowerShellで以下を確認した。
まず、Rancher Desktop関連のプロセスが残っていないか確認した。
Get-Process | Where-Object { $_.ProcessName -like "*Rancher*" -or $_.ProcessName -like "*rdctl*" } | Select-Object ProcessName,Id
このコマンドを実行して、何も表示されなかった。
つまり、少なくともRancher Desktop本体や rdctl のプロセスが動き続けている状態ではなかった。
次に、WSL側にRancher Desktop用のディストリビューションが残っていないか確認した。
wsl -l -v
実行結果には、次のようなWSLディストリビューションだけが表示された。
Ubuntu-26.04-my
Ubuntu-26.04
Ubuntu-24.04
Ubuntu
Factory Reset前に存在していた rancher-desktop と rancher-desktop-data は表示されなくなっていた。
そのため、Rancher Desktop用のWSLディストリビューションは削除済みと判断できた。
次に、自分の環境でRancher Desktopの大きなデータ本体だった、以下の ext4.vhdx が残っていないか確認した。
Test-Path "C:\Users\<Windowsユーザー名>\AppData\Local\rancher-desktop\distro-data\ext4.vhdx"
実行結果は以下だった。
False
False なので、この ext4.vhdx は存在しない。
さらに、C:\Users\<Windowsユーザー名>\AppData\Local の下から、rancher-desktop フォルダ自体もなくなっていた。
この時点で、PCの空き容量も約25GB増えていた。
以上から、今回の環境では、Factory Resetによって rancher-desktop / rancher-desktop-data のWSLディストリビューションと、C:\Users\<Windowsユーザー名>\AppData\Local\rancher-desktop\distro-data\ext4.vhdx は削除されたと判断できる。
そのうえで、Rancher Desktop公式FAQでは、クリーンアンインストールの流れとして、Factory Resetを先に行い、その後でアプリをアンインストールすると説明されている。
そのため、WindowsからRancher Desktopをアンインストールする前に、念のためWSL全体を停止しておく。
PowerShellで以下を実行した。
wsl --shutdown
このコマンドは、正常終了時に特にメッセージを出さない。
ここまで確認できたため、次にRancher DesktopをWindowsからアンインストールする。
この時点で確認できていることは以下である。
- Rancher Desktop関連プロセスは残っていない
-
wsl -l -vにrancher-desktopが表示されない -
wsl -l -vにrancher-desktop-dataが表示されない -
C:\Users\<Windowsユーザー名>\AppData\Local\rancher-desktop\distro-data\ext4.vhdxは存在しない -
C:\Users\<Windowsユーザー名>\AppData\Local\rancher-desktopフォルダ自体もなくなっている - PCの空き容量が約25GB増えた
- 念のため
wsl --shutdownも実行済み
そのため、この後はWindowsの「設定」からRancher Desktopをアンインストールしてよい。
3. Rancher Desktopをアンインストールする
Windowsのタスクバーからスタートメニューを開く。
設定 を開く。
アプリ を開く。
インストールされているアプリ を開く。
Rancher Desktop を探して、アンインストールする。
4. Rancher Desktopを再インストールする
Rancher Desktopを再インストールする。
インストール後、Docker Composeを使う前提なら、Rancher Desktopの Container Engine は dockerd を選ぶ。
これは、この記事の前半でも書いた通り、Docker Composeを普段使いする場合は dockerd のほうが扱いやすいためである。
5. Ubuntu-26.04-my 側でWSL Integrationを有効にする
Rancher Desktopを起動したら、Preferences を開く。
WSL を開く。
Integrations を開く。
Ubuntu-26.04-my を有効にする。
これで、Ubuntu-26.04-my 側から Rancher Desktop の Docker 環境を使えるようにする。
6. Ubuntu-26.04-my 側でDocker環境を作り直す
Ubuntu-26.04-my 側で、移行済みのプロジェクトフォルダに移動する。
cd /path/to/project
そのうえで、必要に応じて次のように実行する。
docker compose build --no-cache
docker compose up -d
これで、Ubuntu-26.04-my 側に移行した docker-compose.yml と Dockerfile をもとに、Rancher Desktop上で新しいコンテナ環境を作り直せる。
この作業で消えるもの、消えないもの
消えるものは、Rancher Desktop側に保存されていたデータである。
Rancher Desktop側のコンテナ
Rancher Desktop側のコンテナイメージ
Rancher Desktop側のDocker volume / containerd volume
Rancher Desktop側のKubernetesクラスタ情報
Rancher Desktop側の設定
古いWSL Integration設定
C:\Users\<Windowsユーザー名>\AppData\Local\rancher-desktop 配下のデータ
消えないものは、Ubuntu-26.04-my 側にtarで移行済みのプロジェクトファイルである。
Ubuntu-26.04-my 側に展開済みのプロジェクトフォルダ
docker-compose.yml
Dockerfile
ソースコード
Ubuntu-26.04-my 側に反映済みの ~/.bashrc の必要設定
外付けハードディスクにバックアップ済みの Ubuntu-24.04-my の ext4.vhdx
ただし、DBデータをDockerの named volume の中だけに置いていた場合、そのDBデータは Rancher Desktop側のデータ削除で消える。
そのため、必要なDBデータがある場合は、事前にdumpしておく必要がある。
今回の目的は、Ubuntu-24.04-my で使っていた古いRancher Desktop環境を引き継ぐことではなく、Ubuntu-26.04-my 側で新しいDocker環境を作り直すことである。
したがって、Rancher Desktop側の約23GBの ext4.vhdx を含めて、一旦すべて綺麗に削除してから入れ直す方針で問題ない。
参考にした公式情報
Rancher Desktop公式FAQでは、クリーンアンインストールは、先に Factory Reset を行い、その後でアプリをアンインストールする手順になっている。
Rancher Desktop公式ドキュメントの Troubleshooting では、Factory Reset の手順として、Reset を押し、確認画面で cached Kubernetes images を保持するか選び、Factory Reset を押す流れが説明されている。
Rancher Desktop公式ドキュメントのWindows向けアンインストール手順では、Windowsの Settings > Apps > Apps & features から Rancher Desktop を選び、Uninstall する手順が説明されている。
Microsoft公式ドキュメントでは、wsl --unregister <Distro> は、対象のWSLディストリビューションに関連するデータ、設定、ソフトウェアを削除するコマンドとして説明されている。
Discussion