Docker DesktopからRancher Desktopに移行してDockerが高速になるか試す

Docker DesktopからRancher Desktopに移行してDockerが高速になるか試す
Photo by Marc Sendra Martorell / Unsplash

2022/06/04追記

続報を書きました。

Rancher DesktopからDocker Desktopに戻した話 - deg84’s blog

Docker Desktopからの移行先としてRancher Desktopを試したいと思います。

Rancher Desktopに期待しているのはDocker Desktopと比べて高速になるかどうかというところ。

今回は実業務でも遅くて気になっているRSpecの実行速度で検証することにします。

ちなみにMacです。

まずDocker Desktopで以下のコマンドを3回実行してみます。

$ time docker-compose run --rm app rspec

結果、平均1040.57sでした。17分ほどかかってますね。

これを基準にして、Rancher Desktopで実行するとどうなるか見ていきます。

Rancher Desktopのセットアップ

まずはインストールから。

"インストーラー"
"Container Runtime"

Kubernetesは使ってないのでstableのやつを適当に入れる。

Container RuntimeはDockerからの移行なのでdockerdにします。

"権限付与"

権限欲しいと言われるので付与します。

"設定"

メモリとCPUはDocker Desktopの設定に合わせて、メモリ16GB、CPU5コアを割り当てます。

"Supporting Utilities"
Insufficient permission to manipulate /usr/local/bin: Error: EACCES: permission denied, access '/usr/local/bin'

permission周りのエラーが出てます。

これはIssueが上がってて、公式FAQにも書いてありました。

FAQには以下を実行して/usr/local/binの所有権を変更して設定するように書いてありますが、あまり変えたくないので今回は手動で対応します。

$ sudo chown $USER /usr/local/bin

手動でdocker, helm, kubectl, nerdctlの4つのコマンドをRancher Desktopのbinを参照するようにします。

$ sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/docker" /usr/local/bin/docker
$ sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/helm" /usr/local/bin/helm
$ sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/kubectl" /usr/local/bin/kubectl
$ sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/nerdctl" /usr/local/bin/nerdctl

Docker Desktopがインストールされている場合、docker, kubectlコマンドはDocker Desktop側にシンボリックリンクが張られているので、Docker Desktopをアンインストールするか、手動でシンボリックリンクを外してからRancher Desktopの方にシンボリックリンクを張る必要があります。

今回はアンインストールすることにします。

Docker Desktopのアンインストール

"アンインストール"

メニューの[Troubleshoot]→[Uninstall]を選択します。
DockerのイメージなどはRancher Desktopに移行しないので全部削除してます。残したい場合はdocker saveなど使うと良いかもしれません。

処理が終わったらApplicationのDocker.appをゴミ箱に捨てます。

Docker Desktopをアンインストールしましたが、docker, kubectlコマンドなどのシンボリックリンクは削除されなかったので、手動で削除します。

$ cd /usr/local/bin
$ sudo rm docker com.docker.cli docker-compose docker-compose-v1 docker-credential-desktop docker-credential-ecr-login docker-credential-osxkeychain hub-tool kubectl kubectl.docker vpnkit

あとはdocker, kubectlコマンドのシンボリックリンクをRancher Desktopのbinを参照するように設定します。

これで一通り動くようになったはずです。

docker-composeのインストール

次にdocker-composeをインストールします。

公式FAQによるとRancher Desktopにも将来的にはdocker-composeが含まれるようになるが今はまだないので手動で入れる必要があるとのこと。

公式FAQに書いてある方法でも良いですが、今回はHomebrewでインストールすることにします。

$ brew install docker-compose

すんなり入りました。

既存プロジェクトの動作確認

docker-composeもインストール出来たので既存プロジェクトがちゃんと動作するか確認します。

$ docker-compose build
$ docker-compose up

エラーが出ました。

error getting credentials - err: exec: "docker-credential-desktop": executable file not found in $PATH, out: ``

調べてみると、~/.docker以下にDocker Desktopの設定が残っていたようです。

削除したほうが良さそうだったので、削除。

$ rm -fR ~/.docker

もう一度実行します。

今度はうまく動きました。

Rancher Desktop(dockerd)でRSpecを実行してみる

一応問題なく動いてそうなので、早くなったか確認するためにRSpecを3回実行してみます。

$ time docker-compose run --rm app rspec

平均で642.58s、約11分と約1.6倍早くなりました!

体感的にはあまり差がなく(11分は結局長い)、それでも計測してみると1.6倍とかなり早くなっているので計測大事だなと思います。

containerdで環境を作ってみる

続いてcontainerdの方でも試してみます。

Rancher Desktopでcontainerdを使う場合は設定画面の[Kubernetes Settings]の[Container Runtime]を[containerd]に変更して再起動すればOKです。

イメージなどは再度ビルドし直す必要があります。

$ nerdctl compose build
$ nerdctl compose up

containerdの場合、dockerコマンド、docker-composeコマンドの代わりにnerdctlコマンドを使います。

containerdでもRailsが動くことを確認できました。

containerdでRSpecを実行してみる

$ nerdctl exec -it app_1 bash
$ time rspec

nerdctl composeにrunがないのでexecで入ってからRSpecを実行します。

こちらは平均で660.91s、約12分とdockerdよりちょっと遅い感じになりました。でもまあ誤差の範囲かなと思ったりもします。

containerdで問題と思うのはdocker、docker-composeコマンドが使えないってところかなと個人的には思います。多分containerdは使わない気がします。

RSpecの実行速度の計測結果

まとめると以下のような感じです。

Docker Desktop Rancher Desktop
dockerd
Rancher Desktop
containerd
1回目 1140.60s 642.37s 656.03s
2回目 960.91s 641.20s 649.84s
3回目 1020.21s 644.18s 676.85s
平均 1040.57s 642.58s 660.91s

計測の結果、Rancher Desktop(dockerd)を使うのが良さそうという結論になりました。

以前、Limaを使って脱Docker Desktopを図ったときは、ActiveStorage周りの挙動が怪しくて移行を断念したことがありましたが、今回はそれもなく問題なく動いているので移行しても大丈夫かなと思います!

Twitter等で見ているとRancher Desktopにした結果、パフォーマンスが劇的に落ちてDocker Desktopに戻した方も居たりするようなので、プロジェクトや使ってる技術によっては高速化は期待出来ない場合もあるのかもしれないです。

なので気になるなら時間があるときに試してみるのが良いかなと思います。