Cosnomi
Cosnomi

医療×IT / 医学生 / Web(React, Flask) / 機械学習(画像認識, Keras)

Twitter / GitHub / Keybase

WindowsのVS CodeからWSL(Linux環境)を使う (Remote-WSL)

私はMacよりもWindowsが好きです。それ自体の好き嫌いというより、自作パソコンが趣味という理由が大きいとは思いますが。―それはいいとして、特にWeb開発においてはWindowsは明らかに少数派です。そのため、時折、環境依存の問題に遭遇することがあります。いえ、時折ではありません。頻繁にです。しかし、Web開発のいわば”標準”であるUNIXをベースにしたMacのほうに分があるのは明らかでしょう。したがって、自分の環境の方をなんとかして標準に近づける必要があります。そこで、今回のRemote-WSLの出番です。

この記事では、Windows上でLinux環境を再現しているWindows Subsystem for Linux (WSL)をVS Codeから利用可能にすることを目的にRemote-WSLについて解説します。具体的にはWSLでインストールされているgitやformatterやlinterなどをVS Codeから利用できるようにすることを目標にします。事実上、WSLからVS Codeを起動しているのと同じようなことができるようになります。

Windows Subsystem for Linux

ご存知の方が多いとは思いますが、まずWSLについて軽く説明します。Windows Subsystem for Linux (WSL)はMicrosoftによって提供されるツールで、簡単に言うとWindows上でLinuxを利用できるものです。Ubuntuなど様々なディストリビューションが利用できます。ファイルシステムなどで例外があるものの、通常の範囲ではネイティブLinuxとの違いを意識する必要はほとんどありません。しかし、Windows上でLinux環境を得ることは、開発にどのようなメリットをもたらすのでしょうか。

大きなメリットは、標準的な開発環境を手に入れられることです。その最たる例はbashで、例えばWindowsのPowerShellやコマンドプロンプトでは当然bashコマンドは動きませんが、WSL上では動かすことできます。これが大きなメリットとなるケースは次のようなときです: node(Web開発)でよく使うnpmにはWindows版がありますが、npm-scriptsには通常、bashのコマンドが使われているためcmd.exeではうまく動きません。しかし、WSLを使えばbashを使えるのでこのような問題は生じません。WSLを用いるとWindwosでも標準的な開発環境を構築することができ、環境由来のトラブルを大きく減らせるのです。

しかし、WSLは通常、CUI環境で動くので、そこでグラフィカルなエディタやIDEを動かすことは現実的ではありません。(できないことはないようですが、かなり不安定のようです。)そこで、Windows上でエディタを動かし、ビルドやlintなどをWSL上で行う方法があり、VS Codeではこれを実現するための強力な拡張機能が提供されています。

Remote Development

VS Codeには最近、Remote Developmentという機能が追加されました。この機能はVS Codeの1.35.0から正式に利用可能です。

これによって、ローカルで動いているVS Codeからリモートで別な環境に接続して開発を行うことができます(しかもそれを意識することなく!)。リモートの環境はWSLに限らず、SSHやContainers(Docker)を含みます。ですから、Remote DevelopmentのうちWSLをリモートとして用いるものは特にRemote - WSLと呼ばれます。
公式ドキュメント(英語)に分かりやすい図が載っていたので引用します。

(引用元: https://code.visualstudio.com/docs/remote/wsl ライセンス: CC BY 3.0 US)

Local OS、つまりWindows環境ではVS Codeが動いています。このVS Codeは純粋にUIのみを担当します。実際にformatやIntelliSenseを行うのはWSL上で動くVS Code Serverです。(図の右側にあるTerminal Process, Running Application, Debuggerがこれに当たります。)さらに、(これは当然のことですが)ローカルのファイルシステムは/mnt/cにマウントされるので、WSL側からこれを操作することも可能です(図の半透明のFile System)。もちろん、WSLのファイルシステムにあるファイルも操作可能です。(図の右上のFile System)

すなわち、ローカルのVS Code役割は極めて限定的で、多くの操作はWSL上で行われることが分かります。

Remote - WSLを始める

Remote - WSLの導入方法は公式ドキュメント(英語)でもよく解説されていますが、非常に簡単ですので、ここでも軽く説明しましょう。

WSLとVS Code(Windows上)の導入は済んでいると仮定します。すると残りのステップは、

  1. Extensionsタブでremote wslと検索し、Remote - WSLをインストールする

これだけです。本当です。

しかし、拡張機能を導入しただけでは今までのWindows上での開発と同じです。実際に、WSLに接続して開発するには Ctrl + Shfit + Pでコマンドパレットを開き、Remote-WSL: New Windowを開きます。続いて、プロジェクトルートを開きます。 cmpl
VS Codeの左下に下図に示すようなWSLの表記があれば、正しくRemote-WSL環境が構築され有効になっていることを意味します。 wsl

新しく開発を始めるときに毎回この操作をしなければならないのでしょうか?答えは、(私の知る範囲では)イエスです。Windows上のVS Codeには2つの選択肢があります。WSL上のVS Code Serverに接続する方法とローカルで完結する方法です。したがって、私達は常に適切な方を選ばなければなりません。一方で、それはRemote-WSL環境を構築しても、Windows環境のみで開発を行う自由があることを意味します。(同一プロジェクトで2つの環境を混在させるのは不適切だと思いますが、プロジェクトごとに使い分けられるということです。)

ちなみに、一度開いたWSLのプロジェクトは下図のように表示されます。先頭が同じなので少し不便な表記ですが、二度目以降はもっと簡単にRemote-WSLの画面を開くことができます。 workspaces

拡張機能

VS CodeとVS Code Serverという2つに分割されたことにより、拡張機能(extension)はそれが動く場所に基づいて2種類に分類されます。1つ目はUIにしか影響しないローカルで動く拡張機能で、VS CodeのExtensionsタブではLOCAL - INSTALLEDに表示されます。もう1つは、WSL環境上で動く必要がある拡張機能で、WSL - INSTALLEDに表示されます。多くの拡張機能は後者に分類されます。lintなどはWSL上のVS Code Serverの役割だからです。

拡張機能は通常、インストール時に正しい場所に配置されるので、普通、この違いをユーザーが意識する必要はありません。しかし、VS CodeとVS Code Serverの2つに分かれていることで、このような違いが生じたということを知っておくことは重要です。

まとめ

Remote-WSLはWindows上での開発から多くの環境依存の問題を取り除くことが期待されています。しかも、表面上は今までの開発とほとんど変わらずにです。いわば、WindowsへのLinux環境の自然な導入です。これは素晴らしいことだと思いませんか。もし、あなたがWindnowsとVS Codeのユーザーなら試してみてください。ほんのわずかな手間で多くのものを得るはずです!

余談: 期待されるWSL2の登場

現在利用可能なWSLはあくまでLinuxのエミュレータです。したがって、いくつかの制限があります。特に、ファイルシステムに関してはWindowsとLinuxの標準的なファイルシステムが異なるため、大きなオーバーヘッドが生じています。(外部パッケージのインストールなどでは大量のファイルを書き込むので、この問題が顕著に現れます。)

しかし、Microsoftは本物のLinuxカーネルをWindows上で動かせるようにするWSL2を開発中で、これを利用することでI/Oの高速化やいくつかの問題の解決が期待されます。記事執筆時点ではWindwos Insidersでのみ利用可能です。まだ少し先の話ですが、WSL2が利用可能になれば、Remote-WSLを用いた開発はより快適になるでしょう。