先日「Visual Studio Codespaces（以下、Codespaces）でVM使うのはコストパフォーマンス的に悪くないんじゃないか」なんて記事を書きました。
今回は正反対のアプローチで、Codespacesで自前のマシンを使う self-hosted という選択肢について書いてみます。
正確にいえば正反対ではなく、全国津々浦々で引きこもっていらっしゃる「今自宅でリモートワークしてるんだけどこれからノートPCである必要ないんじゃない？」というノートPCの相対的な非力さに業を煮やすも今一歩踏み切れない皆様を主に対象とした記事になります。
VS Codespaces self-hostedの特徴
自前のマシンを self-hosted として登録して使う場合、以下のような特徴があります。
- self-hosted machine利用時の場合、Visual Studio Codespacesの利用に関して費用はかからない
- この記事 によると
With self-hosted environments you can register any machine to Visual Studio Codespaces and connect to it from either VS Code or our browser-based editor. Best of all, this is 100% free!らしい
- この記事 によると
- Codespaces CLI（後述）を使うと任意のマシンをVS Codespacesのself-hosted machineとして登録できる
- self-hosted machine上にCodespaces CLIをインストールするだけで良い
- VirtualBox等のVMやdocker containerが利用できるかどうかは未調査（できそうだけど）
これのなにがすごいかというと、Codespaces VMと違ってコストがかからないということもさることながら、自宅に開発用のPC/mac（以下、リモート開発マシン）を設置してそこにリモートアクセスして開発する場合の手間が激減するってことですね。通常、リモート開発マシンを自宅に置いて自宅ネットワーク外からアクセスする場合、たとえば以下のような設定が必要になります。
特に面倒で慎重を要するのがセキュリティ関連の設定で、一歩間違えれば外部からの攻撃者にサクッと乗っ取られてしまうわけで、業務でそのあたりの経験がある方こそ「リモート開発マシンのために業務同等のセキュリティを維持するのは面倒...」と思う方も多いでしょう。そこのところが、CodeSpaces CLIを入れてファイアウォールの設定も変えずにコマンド１つ叩くだけで Visual Studio Codespaces経由で外部からアクセスでき、VS Code（以下、vsc）で開発できるのであれば相当便利と感じる方も多いのではないでしょうか。
実際にやってみた
手元でリモート開発マシンに転用できそうなXPS13(9370) があったので、これに先月出たばかりのXbuntu 20.04 を入れてテストしてみました（Xbuntuを選んだ理由は本記事の最後に解説）。
Codespaces CLIのインストールは簡単に終了
最初にリモート開発機に利用するマシン（現時点ではWindows, macOS, Linuxが対象）でOSをセットアップ、VS Codespacesのpreview利用登録も済ませましょう。
それが終わったら、self-hostedマシンとしてCodespacesに登録するため、現時点でプレビュー版であるCodespaces CLIを https://docs.microsoft.com/en-us/visualstudio/online/reference/vsonline-cli の指示に従っていれます。本記事執筆時点でUbuntu 20.04 用のリポジトリはウェブに記載はないもののURLは存在していようでしたが、うまく動いてないので18.04のものを使ってインストールを完了しました。
aptの設定を終えて apt-get install vso した後は、驚いたことに vso start して支持に従うだけで終わりました。あまりに簡単で拍子抜けしてしまいましたが、途中Codespacesの認証で表示されたリンクを押してブラウザでself-hostedマシンとして認証し、「ユーザーログインしてないときもCodespacesにつなぐ？」的な質問が出てきて Y を選択、という程度でした。他にも１つ質問があったような気がしないでもないんですが、Codespaces CLIのページには vso start にいろいろオプション引き渡すようなことが書いてあったので、普通にコマンド叩いても最後まで行かないだろうからその都度メモを取っていくかと考えていたら、メモを取るまもなく終わってしまったという感じです。セットアップが完了しても「 vso が落ちたらどうなるんだ？」というケースについて自力対応することになると思っていたのですが、まさかプレビュー版ですでに対応しているとは思わなかったです。インストールはほんとにさっくり終わりました。
シンガポールは遠い
現時点では日本リージョンでVisual Studio Codespacesは利用できません。現時点で日本から一番近いリージョンはSouthAsia（シンガポール）のようだったので、そこを使っています。目の前で机に並んでいるPC同士がわざわざシンガポールリージョンを経由してやり取りしているのを眺めるのは複雑な心境です。日本リージョンに来て応答速度が実用レベルになったとしても、なんとなくこの後ろめたさが残る方はいるんじゃないでしょうか。
Remote-SSHとVS Codespacesの併用
そこで考えたのが、自宅で接続する場合は Remote-SSH extensionで接続し、外出先ではCodespacesを経由するという方法です。どちらを使っても応答速度以外はvscでの操作感は変わらないはずだからです。
Remote-SSHとCodespacesで同一ワークスペース（ディレクトリ）を開いてみたところ、Codespaces単体で使うと発生しなさそうなケースがいくつかみられました。まず、当たり前といえば当たり前ですが、物理的に同一なホストでもRemote-SSHで繋ぐ場合とCodespaces経由でつなぐ場合では別のホストとして認識されます。そのため、、Open Recent (Ctrl + R Ctrl + O) で過去開いたファイルやフォルダ、ワークスペースを開こうとすると実際には同じものでもそれぞれ別ホストのものとして認識されます。実際は同じフォルダやワークスペースが２つ表示されるということですね。
また、extensionも別扱いになっているらしく、Remote-SSHで入れたextensionをCodespaces経由で再度インストールしなくてはいけません。ただし、workspace settingsは共有されるので、ワークスペース単位で見ればextensionを入れるだけで済みます。現在 Insider でプレビューになっている Settings Sync が正式リリースされればこの問題は解決するか、少なくとも現時点よりは改善されると思われます。
一方で、これもまた当然な話ですがRemote Settings（ コマンドパレットで Open Remote Settings で編集可能）はホスト毎に行う必要があるので、もしこれを頻繁にカスタマイズしている人がいたら面倒かもしれません。自分はdefault shellの変更) くらいしかやってないのですが、すでにRemote extensionを多用していてカスタマイズしまくってる方は注意が必要かもしれません。
操作感の違い
実際に自宅内LANでRemote-SSH、自宅外ネットワークからCodespaces という使い方をそれぞれやってみましたが、応答速度の違い以外で使い勝手に差はないという印象です。アプリケーションの用途上、双方を同時利用するケースが無いということも大きいかもしれませんね。とはいえ、ファイルを開くときも多少遅さを感じますし、プロジェクトを最初に開いたときやCtrl + P でファイルを探すときなどでもいちいち待たされます。Extensionもものによっては動作が重いですね。現時点でも開発できなくはないですが、快適かというと...。先程も書いたとおり、日本リージョンに来てからが本番でしょう。
ちなみに、私はWSL2を利用する前にHyper-V上のVMでRemote-SSHを使っていましたが、Remote-SSHもRemote-WSLも操作感は全く変わりませんでしたし、Codespaces経由での接続でも変わりがありません。vsc使っていればローカルで開発していても、異なる接続方法でリモートの開発マシンに接続しても操作方法がほぼ変わらないというのはユーザーフレンドリーですね。
なお、こういうご時世で外出先から頻繁に利用する状況が発生していないので vsoコマンドが落ちて外部から接続できないというワーストケースにはまだ遭遇していません。遭遇しないのが理想ですが、リモートワークが解除されるケースについても考慮したい方は、一応対策を考えておく必要はあるでしょう。その場合、Codespaces自体につながらないケースなんかも想定シナリオのひとつになってきますね。
Mac利用前提のプロジェクトをリモート接続で利用する場合の注意事項
最後にリモート開発マシンを用意する上で注意すべきこと、特に開発者が全員Mac利用を想定しているという比較的ウェブ系のプロジェクトではありがちな事項についてまとめてみます。これはself-hostedであればCodespaces VMであれ、Codespaces使わずにRemote-SSHするときでも共通する項目になります。
localhost使えない問題（=事実上localhost固定）
開発環境でブラウザからアクセスするときに、暗黙的に開発者がホスト名でlocalhostのみを想定しているプロジェクトは結構多いんじゃないかと思います。vscが動くマシンとRemote-SSH or Codepsaces で接続するホストが別だと必然的に localhost で参照はできず、hostsファイルを利用するなどしてホスト名を定義する必要があります。利用しているフレームワークや外部サービスによっては追加対応が必要になるケースも有るでしょう。
Macのみ想定されている問題（=開発ツールとサービスが同一ホストにある想定）
localhostのみの想定については hostsファイルでIPとホスト名を対応させるだけで済むケースはあるかもしれませんが、こちらはちょっと厄介なケースもあるでしょう。私が遭遇した範囲で以下のようなものがあります。
- アプリケーション等のサーバーがlistenするIPが127.0.0.1 決め打ちで他のIPアドレスからのリクエストを受け付けてくれない
- デバッグツールがリモート接続を想定していない
- もしくは想定しているはずなんだけど動いてくれない
- macOSでしか動かないソフトウェアが利用されている
１つ目は調べてみるとサーバー立ち上げ時にオプションで指定できたり（0.0.0.0含む）、設定ファイルを変更するとできることが多い印象です。設定ファイル変更が必要可能な場合はホスト名を .env 経由で指定するようになるので、この構成のためだけにPR出したりしなければならないところが気になる人には気になるかもしれません。ノートPCで開発している場合、ファイアウォールで対処できたとしても0.0.0.0 を設定するのは流石に気になるという方はいらっしゃると思いますが、今回のself-hostedの場合は自宅LAN内でルーターでポートを開けたりしていない状態でも使えるので、かなり利用に関する障壁が下がるのではないでしょうか。
２つ目については今の所自分は何かしら回避手段が見つかっているのですが、簡単に行かないケースも多いんじゃないかという気がしてます。やったことないんですが、Chrome DevToolsに繋ぐとかはどうなるんですかね...。sshでポートフォワーディングして解決するか、最終手段は諦めて開発機上で環境整えてX転送あたりなんじゃないかと思いますが、これはこれで別途設定が必要そうですね。
最後についてはリモート開発マシンにMacを使っていれば問題は発生しないでしょうし、Macでなくても本番環境と同じOS（ウェブ系だとLinuxが多いか）であれば比較的クリティカルなケースは少ないと思いますが、どうしても欠かせないソフトがmacでしか動かない場合は詰むので事前調査必須ですね。
気になる人はまず試してみては？
ということで、今回はVS CodespacesとRemote-SSHを使って自宅にいても外出先でも自宅開発サーバーを利用するというアプローチについてまとめてみました。興味ある方で試しにセットアップできそうなPC/Macが手元にあるようなら、一度トライしてみることをおすすめします。特にWindowsでWSL使っている人はリモート開発マシンに実行環境をオフロードすると劇的に速度が上がるので、多少非力なPCでも試してみる価値はあると思います。
おまけ：XPS 13 9370 + Xbuntu 20.04 での設定方法
Codespaces CLIではLinux向けだとshell経由かaptかという選択肢だったので、普段から使っているUbuntu系列にしました。UbuntuじゃなくてXbuntuを選んだのは直接操作するときはGUIが欲しいけどあまりメモリは食いたくない、かといってGUI部分を最低限スレスレを狙うほどでもない、という理由からデフォルトがXfceのXbuntuを選んでます。メモリが気になるなら普通のUbuntu （Gnome 3.36）使っても普段はrunlevel 3で動かすという手もありますし、メモリに余裕があるなら好みの問題だと思います。Ubuntuベースのディストリビューションであれば、本体のほうが躓いたときに調べやすいというメリットはあると思います。なお、Xbuntuの場合 free -h したところ、標準インストール後にrunlevel 5で起動して約1.1GiB、runlevel 3で約600MiB程度でした。
XPS13はclamshellで画面を閉じた状態で使ってます。ログイン後、電源設定で画面を閉じたときにsuspendしないでscreen offになるようにすれば、clamshellモードで動作します。クラムシェルだと発熱が気になるところですが、むしろ画面閉じた状態で立たせておいておくほうが背面の通気孔を机で塞いだりする必要も無く、発熱効率はいいんじゃないかという気もしてます。
