Rancher Desktopは k3sを核とするオープンソースのkubernetesディストリビューションです。Docker Desktopと似たような機能をcontainerdベースで提供します。
config
インストールは公式ガイドのとおり、大きな支障なく完了します。Rancher Desktopアプリを起動するとkubernetesクラスタが起動し、アプリ終了とともにクラスタも停止します。
アプリはGUIのconfigツールですが、現状、CPU/RAMリソースの設定程度しか設定できません。
configファイルは、Linuxの場合、$HOME/.local/share/rancher-desktop/lima/0/lima.yamlにあります。
たとえば、mountsを編集することで、hostPathボリュームからアクセスできるPathを追加できます。
~は最初から設定されているため、hostPathでホストと同じ/home/<user>/...を指定するとコンテナからホストディレクトリを参照できます。
mounts:
- location: /home/<user>/.cache/rancher-desktop/k3s
writable: false
- location: "~"
writable: true
- location: /tmp/rancher-desktop
writable: true
変更はRancher再起動時に反映されます。
UID/GIDがねじれるケースがある
Linuxの場合、hostPathはほぼそのままマウントされるようです。
性能面では有利ですが、コンテナが独自ユーザーを追加しているとUIDが合わずにファイルアクセス不能になります。
たとえば、
Postgresの公式コンテナはUID999のpostgresユーザを追加し、その影響でchownやchmodがエラーになり起動しません。
以下のようなワークアラウンドがありますが、動作に支障が残る可能性があります。
- 一度ボリュームなしで起動し、初回生成されたDBディレクトリをホストにコピー
- コピーしたディレクトリを
chown -R <user>:<user>でホストユーザーに変更 - コンテナをホストのUIDで起動(
securityContext.runAsUser,securityContext.runAsGroup)
- ホストのUIDは、
idコマンドで確認できる
おそらく、ホストUIDと同じUIDを用いてコンテナイメージを独自に作成すると問題なく動作すると考えられます(未確認)。
プライベートレジストリへのアクセス権追加
ServiceAccountにDocker Registryのクレデンシャルを追加することで、プライベートレジストリのコンテナイメージも利用できます。
Google Artifact Registry(pkg.dev)の例は、
プライベートレジストリへのアクセス権を設定で解説しています。
環境切り替え
Rancher Desktopクラスタはkubernetesのコンテキストにリストされ、 kubectl configサブコマンドで、他のクラスタ環境と切り替えられます。
$ kubectl config use-context rancher-desktop
まとめ
LinuxホストのhostPathにやや課題がありますが、その他のマニフェストなどはProductionと同一の構成が動作します。
k8sのDocker互換レイヤは着々と終了しつつあり、containerdベースの開発環境としてRancher Desktopは手軽に利用できます。
ただし、VMのレイヤがネックで動作は相当不安定です。k3sに切り替えたところ安定したためLinuxのRancher Desktopは使いどころがなさそうです。
Chuma Takahiro
関連記事
