Skip to content

MS_RancherDesktop

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 2 revisions

Rancher Desktop for Windows

概要

  • 無償（商用利用 OK）
  • 同様に、WSL2 上の コンテナ・エンジン を操作するフロントエンドとして動作
  • コンテナ・エンジンは dockerd または containerd を切り替え可能
  • この切り替えは、rdctl set --container-engine で行う（rd 制御用 CLI）。
  • dockerd を選んだ場合は Docker CLI、containerd を選んだ場合は nerdctl が同梱される。
  • docker.exe / docker-compose.exe で、Rancher Desktop が管理する WSL2 VM へ透過的に接続。
  • Kubernetes(k3s) がオプションで内蔵、ローカル K8s クラスタが立ち上がる（kubectl、Helm も同梱）。

移行メモ（体裁）: 原典の「WLS2」は
「WSL2」の誤字であるため修正した。

補足（「無償（商用利用 OK）」が冒頭に来ている理由）: これは
Docker Desktop の有償化（2021 年）を受けた記述である。

【2021 年 8 月〜】Docker Desktop のライセンス変更
  従業員 250 人超 かつ 年商 1000 万ドル超の企業では有償サブスクリプションが必要
     ↓
  多くの企業で「Docker Desktop を使えない」状況が発生
     ↓
  代替として Rancher Desktop / Podman Desktop に注目が集まった

3 者の位置付けは次のとおり。

Docker Desktop Rancher Desktop Podman Desktop
ライセンス 条件付きで有償 無償（Apache 2.0） 無償（Apache 2.0）
提供元 Docker 社 SUSE Red Hat
エンジン dockerd dockerd / containerd を切替 Podman（デーモンレス）
Kubernetes 内蔵（kubeadm） 内蔵（k3s） Kind 経由
docker コマンド ネイティブ 同梱（dockerd 選択時） エイリアス（podman の別名）

Rancher Desktop の特徴は
**「エンジンを切り替えられる」**点にあり、

  • dockerd：既存の docker コマンド・スクリプトがそのまま動く、
  • containerd：Kubernetes と同じランタイムで検証できる（本番に近い）

という使い分けができる。
本番が AKS であれば containerd を選ぶ方が
挙動の差異が少ない。

詳細

特筆すべき点は特に無いが、以下は検証結果。

移行メモ（体裁）: 原典の「特筆スべき点」は
「特筆すべき点」の誤りであるため修正した。

インストール

診断ログ

診断ログ（Diagnostics）を確認し（、AI によって指示された）、以下の手入れを行った。

  • wsl の最新化

    wsl --update

  • wsl の再起動

    wsl --shutdown

  • 旧ファイルの削除

    wsl -d Ubuntu-24.04 rm -rf ~/.kube/config

この後「Rancher Desktop」を再起動・再診断し問題が 0 になっていることを確認。

補足（~/.kube/config を消す理由）: 3 つ目の操作が
一見乱暴に見えるが、理由がある。

~/.kube/config は kubectl の接続先設定であり、

【問題が起きる流れ】
  以前に Docker Desktop や別ツールで K8s を使っていた
     ↓ ~/.kube/config に古いクラスタ情報・証明書が残る
  Rancher Desktop が k3s のエントリを追記しようとする
     ↓ 既存エントリと衝突する／古い context が優先される
  「クラスタに繋がらない」「認証エラー」

という事象が起きる。
設定ファイルは再生成されるため、消すのが早いというのが
この手順の趣旨である。

ただし、他のクラスタ（本番の AKS 等）の接続情報も
同じファイルに入っている場合、消すとそれも失われる。
実務では、

# 消す前に退避
cp ~/.kube/config ~/.kube/config.bak

# あるいは、該当の context だけ削除する
kubectl config delete-context <名前>
kubectl config delete-cluster <名前>

とする方が安全である。

なお、wsl --shutdown はすべての WSL ディストリビューションを停止する。
他の作業中の WSL があれば巻き添えになる点に注意する
（Windows Subsystem for Linux）。

実行確認

補足（移行時に確認すべき点）: 「通常通り実行できる」とあるが、
Docker Desktop からの移行で引っかかりやすい点を挙げておく。

項目 注意
既存のイメージ・ボリューム 引き継がれない（別の VM のため）。再ビルド／再作成が要る
docker-compose v1 形式（docker-compose）と v2（docker compose）の差異
ボリュームのマウント Windows のパス指定の扱いに差が出ることがある
ポート フォワード localhost への公開の挙動が微妙に異なる場合がある
ファイルの権限 WSL2 のファイル システム越しの権限
性能 Windows 側のフォルダをマウントすると遅い（WSL2 内に置くと速い）

最後の性能の問題は Docker Desktop でも同じで、
ソースコードを /mnt/c/... ではなく WSL2 のファイル システム内に置く
のが定石である。

参考

Tags: 移行, Windows, Hyper-V, 仮想化, コンテナ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally