VS Code ServerのPrivate Previewに参加できたので触ってみる
以前からwaitlistで待っていたVS Code ServerのPrivate Previewに追加された通知が2022/09/23に届いていたので早速触ってみる。
(ちなみに、リモートから触る必要がなくてローカルホスト上で動けばいいのであればPrivate Previewへの参加は不要。ただしLAN内でも別マシンからは接続できない。)
スキマ時間にちょこちょこ触る系の開発はメインマシンだったりサブのmacbookだったりいろんなマシンから作業したいので、リモートに開発環境を置いて一元化できると楽でよい。iPadからも快適に触れるともっとよい。
これまではリモートに置いた環境にssh越しにvimで作業することが多かった。
自宅サーバのProxmox上にLXCでVSCode Server専用のインスタンスを建てた。リソースはとりあえず2Core 8GB。
OSはUbuntu 22.04。まだ公開鍵でsshできるように設定しただけ。
入れたパッケージもgithubから公開鍵を取ってくるためのcurlと環境確認用のneofetchだけ。
VSCode Serverの構築ドキュメント。
配布されてるshスクリプトで全部やってくれるらしい。サンプルはwgetだがスクリプトの中身を見たらcurlでも動くようなのでcurlでやる。
curl -sL https://aka.ms/install-vscode-server/setup.sh | sh
動作要件。
要件はRemote DevelopmentのHostになるときと共通っぽい?
インストールできたらしい。(successくらい言って欲しい)
利用規約に同意してサーバ起動。Githubログインが必須。
利用時はGithub + Microsoftアカウントでのログインが必須で、サーバ側で認証したアカウントと同一アカウントじゃないと接続ができないようになっているので安心。
ブラウザから接続。クライアントとホストが別マシンなので、ちゃんとトンネリング経由で接続できてるっぽい。
ブラウザのタブから直接触ってると殆どのショートカットがブラウザに持ってかれて悲しい気持ちになるので、ChromeなりEdgeなりの機能でアプリ化しておくとよい。
こうなるともうほぼまんまVSCodeだなあ。
リモートホストのシェルがそのまま使えて便利なんだけど、ターミナルの入力はもたつく?
バッファリングはしてくれてるみたいでちょっと不思議な感じ。
普段vimばっか使ってるのでわからないけどRemote Developmentでsshしたときもこんな感じなんだろうか。
拡張機能もちゃんと使える。
ayu(カラースキーム)はリモートホストに、vim拡張はローカル側ブラウザにインストールされたっぽい。
てことはvim拡張の方は共通化してくれなくて各マシンで入れなきゃいけないのか?これの確認はそのうち。まあ最初の一回だけだし。
開発環境を構築してみる。
このインスタンスには複数の開発環境を同居させたいので、プロジェクトごとにDockerで開発環境をコンテナ化しておきたい。VSCodeのDocker統合がVSCode Serverでもちゃんと機能するか確認する。
ホストにDockerを入れる。とりあえず一番面倒がないaptのリポジトリにあるpackageを使っておく。
せっかくなのでブラウザ上のVSCodeクライアントから。
これでDockerが使えるようになった(sudoで使いたくないので実行ユーザをdocker groupに追加して、反映のために一度code-serverを終了してシェルにログインしなおすなどした)
雑にslidevのプロジェクトを作る。ホスト側は可能な限り汚したくないのでセットアップも一時的なDockerコンテナを建ててやる。
雑にdocker-compose.ymlを書いて動作確認。
コンテナを起動しただけで勝手にポートフォワーディングが始まって、クライアント側のブラウザで開けるようになった。やるじゃん。
これもVSCode Serverと同じくvscode.devのトンネリング経由みたいなのでGithubでのログイン必須。
.devcontainer/devcontainer.json
を用意。とりあえず最低限。
あ、Remote - Containersの拡張がブラウザ版VSCodeに対応してないらしい。残念...
クライアント側でVSCodeのアプリを実行している場合ならssh越しのホスト上のDockerコンテナを使ったRemoteコンテナができるので、そのうちできるようになるのかなあ。
現状こういう使い方をしたいならクライアントにVSCodeを普通にインストールしろという事になりそうだ。
docker-composeでアプリ起動できるならよくない?と思いきや、この状態だとコンテナ上にLSPを押し込んでVSCodeで補完を効かせたりができない。(コンテナのポートを追加で開けてTCP越しに喋らせられるLSPなら使えるかもだけど試してない)
node_modulesもnamed volumesに展開しててホストからは見えないのでこの辺の補完も効かないだろうなあ。
まあどうせProxmox上のインスタンスなのでプロジェクトごとに1インスタンス建てたり、ホストが汚れるのを気にせずにガンガン環境構築していけば全然使えるって感じ。
まとめ
トンネリングが便利
- LAN内外を問わず、ブラウザが使える端末ならどこからでも文字通り「いつもの」VSCodeに繋がってよい
- リモートホストでlistenされたポートに対しても勝手にトンネリング経由のポートフォワーディングをしてくれて体験がよい
拡張機能の対応状況は完全ではない
- 「リモートホスト上にDocker環境を構築して、Remote - Container拡張でコンテナ開発環境を利用する」みたいな用途がダメ
- 全部は見てないが他にも使えない拡張はありそう
- いずれできるようになる説はありそう
クライアントにVSCodeを普通にインストールしてVPN + sshなりでRemote Development拡張使って開発サーバに繋げばよくない?と思うかもしれないが、VSCode ServerはWebブラウザ完結 = クライアントにアプリを入れなくていい ところが強みだと思う。
それこそiPadでも使えるし。(iPadOSのSafariで快適かはしらない)
それ以外のところはやろうと思えば既存の仕組み(VSCodeをクライアントにインストールして、vpn + ssh越しにRemote Development拡張使うとか)で満たせるし、macOSやLinuxのクライアント使ってると恩恵薄いかなあ。ChromebookとかiPadがメインの人は嬉しいのかな。
あとこれサーバとして常駐するならsystemdのサービスとかにしておきたいわね。