【R】DockerでRStudioを使う個人的ベストプラクティス

この記事で紹介したDockerイメージのバージョン3.xがもうメンテされていないっぽい（GitHubリポジトリが読み取り専用になっている）。
記事後半で4.xの使い方も紹介していので、今後はそっちを使った方がよさそう。

概要

以前「renvとdockerによるRの分析環境構築」という記事を書いたのだが、あれから自分の思うベストプラクティスが変わったので改めて記事にする。

準備

Dockerが使えればOK。WindowsでWSL2を使うなら.wslconfigに以下を記載しておく。

.wslconfig

[wsl2]
localhostForwarding=True

手順

手順といっても 以下のコマンドでRStudioを起動するだけ！ あとはブラウザでlocalhost:8787にアクセスし、好きなようにRStudioを使えばよし！ただ、新規にProjectを作るときはコツがるいるため以降で少し解説。

# aliasとして設定しておくと快適
docker container run \
  --rm \
  -e DISABLE_AUTH=true \
  -p 8787:8787 \
  -v $HOME/.renv:/home/rstudio/.local/share/renv \
  -v $(pwd):/home/rstudio/project \
  rocker/rstudio:3.6.3

新規にProjectを作成

まっさらなディレクトリから始めるとしよう。そのディレクトリでRstudioを起動したら、左上のCreate a project→Existing directoryと進み~/project（ホストマシンのワーキングディレクトリがここにマウントされている）を選んでCreate Projectを押す。まっさらだったディレクトリにproject.Rprojというファイルができたはず。

Projectができたらrenvの設定もしてしまおう。RStudioのコンソールで以下を実行する。

install.packages("renv")
renv::init()

既存のProjectを利用

ProjectのディレクトリでRStudioを起動しprject.Rprojを選択すると既存のProjectを開ける。renvもちゃんと有効になる。

解説は以上。特に難しいことはないが、何か疑問があれば下のQ&Aを見てもらうとよいかと。

Q and A

rocker/rstudioって何？

公式ページはこちら。公式ブログでも紹介されるくらい人気のDockerイメージらしい。ちなみにrocker/rstudioで動かないパッケージがあれば、イメージは大きくなるがrocker/tidyverse・rocker/verseを順に試してみるとよさそう（諸々apt-get install済みだから）。

Rのバージョンはどう切り替えるの？

上記コマンドのタグ（3.6.3）を変更すれば簡単に他のバージョンを使える。利用可能なタグはここで確認できる。
ちなみに4.0.0以降とそれ以前ではGitHubのリポジトリが違うためIssueを探すときは注意すること。そのタイミングで仕様についてもいくつか変更が加わっているてめ、READMEのこのあたり見ておくとよさそう。そして、起動コマンドも以下のように変更が必要¹（rocker/rstudioではなくrocker/verseを使っているのは、このIssueで議論されているWarningを回避できそうだから）。

# 4.0.0以降の起動コマンド
docker container run \
  --rm \
  -e DISABLE_AUTH=true \
  -e RENV_PATHS_CACHE=/renv \
  -p 8787:8787 \
  -v $HOME/.renv:/renv \
  -v $(pwd):/home/rstudio/project \
  rocker/verse:4.0.0

インストールしたパッケージはどこにいくの？

-vオプションでホストマシンの$HOME/.renvを指定しているため、きちんとrenvが機能していればそこにキャッシュされる²（キャッシュが何だかわからない方は、ドキュメントのこのあたりを読むとよいかと）。キャッシュが機能しているとinstall.packages()の際、以下のようにlinked cacheと表示される。

前回の記事はDockerイメージにrenvを含めていたが？

前回の記事ではrenvをインストールしたDockerイメージを自前で用意したが、今回はしなかった。Dockerイメージを管理するのが面倒だというのが一番の理由。renvは必要なタイミングでわりと勝手にインストールされるし、Projectのディレクトリに保存されるから同一Projectで複数回インストールされるといった無駄もなさそうなので、問題ないかなと。

まとめ

今回紹介した方法のメリットを改めてまとめておく。

• 環境構築が簡単（Dockerのインストールのみ）
• 再現性を担保しやすい³（R本体はDockerだし、パッケージもrenvで管理）
• RのバージョンをDockerイメージのタグで明確に指定できる
• ホストマシンの環境を汚さない（renvのキャッシュができるのみ）

また、本文中で触れなかったが、短所についても簡単にまとめておく。

• パッケージのインストールに時間がかかる場合がある⁴
• Dockerコンテナが変わるとRStudioの設定が一部引き継がれない（ProjectOptionsは引き継がれる。GlobalOptionsはだめ）-vオプションで設定ファイルを/home/rstudio/.config/rstudio/rstudio-prefs.jsonとして渡せば解決

そもそも自分は頻繁にRを利用するわけではないため、気づいていない問題点があったら申し訳ない。

1. 最初に紹介したコマンドだとroot権限で/home/rstudio/.local/shareが作成されるのだが、それが4.0.0以降だと問題になるっぽい。逆に4.0.0以降用に紹介したコマンドを3.6.3とかで使うと、環境変数の受け渡しでうまくいかない。共通のコマンドにしたかったのだが断念。。。 ↩

2. 再現性を担保するため、基本的にrenvは使うべきだと思う。ホストマシン側にキャッシュされるからDockerコンテナが消えても問題ない、というのがポイント。 ↩

3. 再現性を担保するなら、set.seed()とかも適切に使うこと。 ↩

4. Linuxだとインストール時に手元でコンパイルが走るため。4.0.0以降はRSPMがデフォルトになって改善したが、それでも手元でコンパイルが走ることはあるようだ。ホストマシンのスペック的にコンパイルが不可能な巨大パッケージは、つよつよGCEでコンパイルしてキャッシュを手元に送るとかで対処。GCE使うのが面倒ならCloudShellとかもけっこう強いよ。 ↩