VSCodeのRemote - WSLで業務開発
#Elm #Elixir #VSCode #WSL #Windows #リモートワーク #WfH #WorkFromHome #StayHome
使ってる言語は主にElm, Elixir。他の技術要素はDocker, AWS, CircleCIなど。
2018,19くらいはElm development on Windows with Atomで自分なりにパターン作ってたのだが、その後VSCodeに移行した
VSCodeでもElmLSが発達してきて、当初はElmjutsuにしかなかった機能も徐々に実装が進んだので、Elmの開発については問題なし
https://github.com/elm-tooling/elm-language-server
https://github.com/elm-tooling/elm-language-client-vscode
Elixir開発も、forkのElixirLSがそこそこメンテされてるので十分
https://github.com/elixir-lsp/vscode-elixir-ls
最近originalから正式に移譲されてmainstreamになった
2020/04はCOVID19のために完全リモートワークとなり、自宅で作業する機会が増えたので再訪
個人的には私物Macもあるのだが、PCデスクは主にゲーム用なのでハイスペックWindowsマシンが居座っており、MacBookを置くと狭い。Windowsマシンで業務開発もできるとベター
TLDR
ほぼ問題ない
Cocoa Keybindがないことだけが最大の弱点だが、これは他のLinuxでも同じ
前提
Windows 10 Pro/Enterpriseが必要
社用アカウントやデータアクセスがディレクトリ管理されている場合、会社からも要求されるだろう
なぜならBYODで社用アカウントを利用したければPro以上のライセンスが要るため
Zero Trust Network
そうでなくても、最新版のDockerを使いたければ2020/04現在はProでなければならない。Hyper-Vを必要とするため
VirtualBoxベースのDocker Toolboxもあったがもはやレガシーとされている
=> だったのだが、WSL2の到来(May update以降)で不要になった。バンザイ
=> VSCodeとWSL2で業務開発
方法
WSLはもともとそれなりに使えるようにはなっていたが、Dockerが利用可能な環境になればブロッカーがほぼ無くなる
逆にHomeライセンスだとInsider PreviewビルドでなければDockerが使えない。それはキツい
WSL2が来れば使えるようになるらしいが、まだInsiderテスト中
注意点として、/etc/wsl.confを更新してDrvFsのmetadataオプションを有効化しておく
するとマウントされたWindowsファイルに対してもLinux permをちゃんと保存できるようになる
何故かデフォルトで有効になっていない
umask/fmaskはセットしなくていい。
https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/
VSCodeの最近の公式拡張であるRemote Developmentを利用する
ホストマシンとは別の外部サーバやコンテナなどにアタッチして開発を行える拡張
SSH, Container, WSLなどの選択肢が用意されている。その中でRemote - WSLを使うというわけ
何ならSSHでアタッチとかもできるわけなので便利
WSL内にVSCodeのサーバプロセスが動き、ホストマシン側で起動したVSCodeとコミュニケーションして動作する
当然ながらこのコミュニケーションオーバーヘッドにより、動作は多少遅い
特に保存時にビルドやフォーマットなどの重い処理を行うLanguage Server系拡張
が、スペックが十分なPCであればそれほど気にならない程度には速い
参考に私の環境: /gada-games/自宅PC周辺環境
WSL側にインストールされているコンパイラ、ランタイム、ツールなどに依存する拡張は、WSL側にインストールして使用することができる
ホストWindowsに色んなものをインストールする手間が省ける
Q. Macみたいなキーバインドにしたいんだけど?
A. AltをCmdに見立てて一つ一つ移植する
MacはデフォでCocoa Keybind (Emacsライクなカーソル操作)が使えて便利だが、残念ながらWindowsではこれと「同じ」体験に持ってくのは難しい
VSCode内部限定でなら大体同じにできる
ただしOptionを要求するキーバインドは適当に置き換えること。そんなに多くないはず
Homebrewを使う
https://docs.brew.sh/Homebrew-on-Linux
Mac向けの開発環境構築ではすでに使ってるところが多いだろう
Linuxbrewが2019年に公式化され、さらにbrew自体のインストールスクリプトもruby依存が除去されてよりportableになり、WSLでもしっかり使える
Brewfileを使ったbrew bundleを利用すれば、Mac環境と合わせるのも簡単
Dockerを使う
Docker for Windowsをインストールすれば良い。WSLからも使える
ただ、dockerスクリプトが用意されていないため、エントリポイントがdocker.exeになっており不便だし、dockerの存在を前提としているスクリプトが動かなくなる
PATHを通してある適当な場所に以下のようなshellscriptを置いておく
code:shellscript
#!/usr/bin/env bash
"/mnt/c/<path to docker bin>/docker.exe" $@
docker-composeも同じ
将来的にちゃんと.exeなしファイルが用意される可能性もあるので、このスクリプトは$HOME/binとかの制御しやすい場所に置くのが良い
Completionのたぐいは多分これでも動くはず。私はfish-shell+docker-completion (個別にbrewでインストール)だがちゃんと動いている
HomebrewとDockerがあれば大抵の開発環境はMacと同様に揃えられるはず。以下その他
コンパイラやランタイムのたぐいはasdfで管理するのがおすすめ
https://qiita.com/ymtszw/items/28cc7a000236510b71c2
JDKが必要で、Oracle JDKでなくても良いなら、AmazonのCorettoがおすすめ
https://aws.amazon.com/jp/corretto/
これらを使わないとしても、基本的にはLinuxなので、各ツールのインストールドキュメントのLinuxの説に従えばOK
Windows, WSL開発環境の弱点、注意点、動かないもの
逆に言うと、以下で上げてる問題点以外は驚くほどちゃんとできている
VSCodeのProject Manager拡張がremote pathに未対応
https://github.com/alefragnani/vscode-project-manager/issues/345
CircleCIのCLIで、なぜかcircleci local executeできない
手元で起きているのは https://github.com/CircleCI-Public/circleci-cli/issues/381
繰り返しだが、MacのCocoa Keybind (Emacsライクなカーソル操作)がないこと