【vscode】devcontainerのClone in container volumeがよいという話

こんにちは、 ryosuke です。

今回は、 vscodedevcontainer を使った開発環境について、 「Clone repository in container volume」を使うとうれしい点を取り上げます。

「Clone repository in container volume」とは何か

vscode で devcontainer を使った開発環境を構築する場合、下記のような手順を踏むことが多いと思います。

  1. PC の任意のフォルダに repository を clone する
  2. 該当フォルダを vscode で開く
  3. vsocde 上で Dev Containers: Open Folder in Container... コマンドを選択する
  4. devcontainer による開発環境が起動する

Clone repository in container volume (以後 cloneInVolume) の場合、「PC の任意のフォルダに repository を clone」 ではなく「devcontainer の volume に repository を clone」する点が特徴です。

うれしいこと

Bind mount による諸問題からの解放

vscode の記事 「Improve disk performance」 にもあるように、 Windows や macOS 向け Docker Desktop では「Bind mount したファイルへのアクセスパフォーマンスが悪い」という課題がつきまといます。
改善策として「依存ライブラリをインストールするディレクトリを volume mount 化」したり、 Windows では「clone 先を WSL のファイルシステム上に変更」したり、 macOS では「Docker の --volume フラグのチューニング」や「bind mount driver を変更」する方法があります。

しかし、 cloneInVolume を使えば、そもそも bind mount するファイルが1つもなくなるため、この課題とは無縁になります。
上記のような Host OS ごとに異なる改善策をとる必要もありません。

開発環境起動の直リンが作れる

このバッジ「Open in Dev Containers」をクリックすると、 microsoft/vscode-remote-try-java repository の devcontainer 環境が cloneInVolume で立ち上がります。 (事前に vscode のインストールは必要)
このような Web リンクをつくることができるので、新参者でも開発環境を立ち上げるのが一掃簡単になることが期待できます。

制約事項

特殊な repository 構成・運用に対応していない

現在のところ、 repository を特殊な構成・運用にしている場合は、 cloneInVolume が正しく立ち上がらないようです。
実際に試してみて、うまく動かなかったケースは以下の通りです。

  • 複数の repository を clone する必要がある場合
  • git-lfs を使う repository の場合
  • submodules を使う repository の場合

Host OS から repository 内の file にアクセスする手段が限定される

開発に必要な全てのファイルが Docker 管理下にあるため、Explorer や Finderを含む Host OS のアプリケーションからファイルを操作する手段がありません。
したがって、 vscode や Extension、devcontainer 内のコマンドだけで開発可能な環境である必要があります。

おわりに

ぜひ皆さんも、直リンバッジをクリックして cloneInVolume の良さを体験してみてください。