5/20(土)に開催されたOpen Source Conference 2023 Online/NagoyaでVisual Studio Codeで始めるリモート開発入門というタイトルでセミナー登壇した際に、「割と使い勝手良さそうなので、プレビュー版だけど社内の内製化プロジェクトで使ってみる」的なことを言ってから1ヶ月くらい経ちました。当日のセミナー内容が気になる方はこちらのリンクからアーカイブ動画と資料を見ることができます。

↓動画アーカイブはこちら↓
Visual Studio Codeで始めるリモート開発入門 2023-5-20 D-3 - YouTube

↓資料はこちら↓
Visual Studio Codeで始めるリモート開発入門 - Speaker Deck

結局使ってるの？

「....それで、あの後導入したの？」
はい。あの後すぐに早速開発プロジェクトに導入して有言実行しました。
開発規模が小さいプロジェクトで1人で回しているので他メンバーの説得などなく自分が手を動かせれば導入できる、というくらいのものでした。
このような新しいツールを入れる際には最初の関門になりやすいところですが、この辺りの話を期待されていた方にはこの後のお話は読み応えのない内容になっていると思います。

Dev Containersとは

Visual Studio Codeの拡張機能の1つで、Dockerコンテナを使用してVisual Studio Codeのフル機能を使用できる開発環境を構築できる仕組みのこと。
主なメリットは次のような点が挙げられます。

コンテナ技術どうようにデプロイ先のOS上で一貫性があり、再現性の高いツールとして開発できる
ローカルマシンへの影響を心配することなく、異なる開発環境間で素早く切り替えができる
新しいメンバーと一貫した開発環境を構築できて配布が容易になるため、初期構築の手間を減らせる
ローカルマシンや他の環境に影響を与えないため、新しいバージョンやパッケージなどを試しやすい

リモート開発とは

リモート開発とは、ローカルマシン以外でVisual Studio Codeのフル機能を使用して開発できる環境のこと。コンテナやAWSのEC2などのリモートマシン、Windows Subsystem for Linux(WSL)などの環境を使用できる。
リモート開発を使い始める際は、Visual Studio Code Serverがリモートマシン上にインストールされて起動されます。
ソースコードのクローンやアプリケーションの実行に必要な環境はすべてリモートマシン上に構築されるため、ローカルマシン上では何もインストールされません。

Visual Studio Code Remote Development

使い始めるまで

まずは必要な拡張機能と開発環境を構築する場所を決めます。

必要な拡張機能

ローカルマシン上のDockerコンテナ上に構築する場合

Dockerが動けばどこでも良いためローカルマシン上のDockerコンテナ上に構築する場合は、この拡張機能だけあれば最低限揃います。

Dev Containers - Visual Studio Marketplace

リモートマシン上で構築する場合

リモートマシンに接続する際に要求される接続方法によって使用する拡張機能が異なります。
基本的にはSSHもしくはトンネル(VPNなど)経由ではないでしょうか。使用する方法に応じて次のいずれかの拡張機能をインストールします。

Remote - SSH - Visual Studio Marketplace

Remote - Tunnels - Visual Studio Marketplace

これらを1つ1つインストールしても良いですが、拡張機能パックと呼ばれるあらかじめよく一緒に使われる拡張機能をまとめてインストールできるようにしてくれている拡張機能があります。
リモート開発系であれば以下のような名前で提供されています。

marketplace.visualstudio.com

どこに構築するか

リモートマシン上で構築する場合はどこで構築するかを決める必要があります。
次の点が検討するポイントになると思います。

何をやろうとしているか
会社や組織で使用できる選択肢を知る
コスト

何をやろうとしているか

最近ではAI系もかなり人気が出てきて、かつてのクラウドブームのような感じがします。
急にAI系やってくれと言われたけど、手元の端末で学習モデルを作成しようとしたが今の端末ではかなり時間がかかってしまうこともあります。
スポットでかなりマシンスペックを消費するものの普段はそこまで使用ない場合は、ハイピークに合わせてマシンを調達してしまうと持て余してしまうことにも繋がります。
このように使用する頻度やタイミングが極端に偏っている場合などは、必要に応じてマシンスペックを切り替えられる環境を選択すると良いのではないでしょうか。

所属組織で使用できる端末やサービスの選択肢を見つける

コストを気にしなければ、AWSのEC2などのクラウドサービスを活用することです。必要に応じて柔軟にスケールさせることができますし、ハードウェアの調達が不要なところも手軽です。これはクラウドのメリットとほぼ同じです。
所属組織や団体によってそもそも外部サービスの使用が制限されている場合は、パブリックなサービスを使用することは難しいかもしれませんが、社内サーバーや遊休端末を活用することも少しネタ的な感じになりますが方法の1つだと思っています。
1番お勧めしたいのは、クラウド化の波に追われて役目を失ってしまったオンプレ環境のリソースを再利用することです。最悪のケースでもこれまでのやり方のローカルマシン上で作業ができるため、高可用性を求めなくても良く勉強がてらに気軽に運用もできる点でもお勧めです。

コスト

1番悩ましいところはコストの面ですね。クラウドサービスの活用が柔軟で手っ取り早くはあるものの、ラーニングコストなど追加費用がそこそこかかるところではないでしょうか。
しかし、低コストを求めていくとローカル端末上にあれこれ構築したくなりますが、昨今の開発環境に求められるスペックはかなり大きくなっています。また、半導体不足や円安などこれまで気にもしなかったような情勢で要件を満たすようなスペックの端末を調達しようと思ってもいいお値段になってしまうということもあります。
この辺りは捉え方によって良し悪しが変わってくるためこれがベストと言いにくい点はあります。

弊社では

あまり参考になりにくいと思いますが、社名に仮想化技術という名前がついているくらいなので、検証用に個人が自由に使える仮想環境が提供されています。私自身もそこそいいスペックのMacbookくらいの仮想環境を立ち上げてその中で複数のリモート開発環境を動かしています。

開発で使ってみてどう？

メリット

個人的には次のような点にメリットを感じました。

ローカルを汚さない開発はいい
ローカルマシンが軽い
サブ端末を使っても同じ開発環境をすぐに手に入れられる
必要におじてスペックを切り替えられる
Configuration as Code (CaC)がやりやすい
VS Codeレベルで環境を合わせることができる

ローカルを汚さない開発はいい

文字通りなのですが、ローカルにあれこれ実行環境を入れていると時々他の環境と競合したりして、おかしな挙動をしたりすることがありました。
リモート開発環境に切り替えてからは、Dockerコンテナ同様に必要なものしか含まれていない環境で開発を行っているので変なエラーなどに悩まされずに済みます。
他にもメジャーバージョンアップに向けてあこれ必要な修正などを加えていくものの、専念することができず片手間で作業したい時にもバージョンをいちいち切り替えずに別の環境に分けて作業ができるため、快適です。
片手間だったら進められるのにというようなタスクは捗るのではないでしょうか。

ローカルマシンが軽い

大部分の処理は全てリモートマシン上で実行されているため、これまで端末のファンが回ってうるさかったのですが今は静かです。
ローカルマシン上でDockerなどを動かす必要もないため、そこまでスペックがなくても快適に作業ができそうです。
あれこれオフラインのイベントが復活してきているので、15インチのMacbook proを持ち運び回るのはかなり辛いところがあったので、持ち運び用でMacbook Airを社内で相談しているところです。

サブ端末を使っても同じ開発環境をすぐに手に入れられる

チームメンバーと開発環境を共有しやすいという点と同じメリットになるのですが、他の端末に切り替えても開発環境の実態はリモートマシン上で保持されているため、クライアント端末は何で動かしても基本的には同じになります。
VS Codeのユーザー設定として保持されているようなものは引き継がれないのでアカウント連携して設定を保持してもらうようなことが必要ですが、その設定をしてしまえば同じように使えます。

必要におじてスペックを切り替えられる

クラウドサービスのメリットになりますが、自由にスペックを変えることができるため、重めのビルド処理をするときやAI系などGPUを多く必要とするなどのシーンに応じてマシンスペックをカスタマイズできるところはいいです。

Configuration as Code (CaC)がやりやすい

Dockerコンテナの技術と同じように必要なツールなどを全て定義することもできますが、VS Codeまわりでもメリットがあります。例えば、拡張機能を設定ファイルに記載しておくと、自動でインストールしてくれるところです。必要な拡張機能を整理していくとそこそこの数になることになるのでポチポチしながらインストールする手間がなくなります。

デメリット

デメリットに感じたところは次の点です。

環境の立ち上げとリロードは割と時間がかる
Dev Containersに関わるファイルに不備があるとローカルで編集が必要
ネットワーク品質に左右される
機密情報などをどう保持するかは悩ましい

環境の立ち上げとリロードは割と時間がかる

Dockerコンテナと同じですがイメージビルドしている待ち時間があるため、ローカルマシン上で使っているような感じで手軽に使うこはできないです。
VS Codeも時々うまく動かなくなってリロードをすることがあるのですが、リロードを気軽にしたくない心理が働いてしまいます。

Dev Containersに関わるファイルに不備があるとローカルで編集が必要

細かい話ですが最初からリモートマシン上で開発をしようとしても、そもそもの構成ファイルに不備があると正常に起動できないため、リカバリーモードで立ち上げる必要があります。その点は少し不便ですが、ローカルマシン上のDockerコンテナで起動する必要があります。最初からリモートマシンを使っているとそこまで不便ではないので、構成ファイルの作成を試行錯誤している間はローカルマシン上で動かして作業する方が良さそうでした。

ネットワーク品質に左右される

これが1番ネックだと思いますが、ネットワークが遅いと環境自体も遅くなってしまいます。もちろんですがネットワークが繋がらない環境下であれば、リモート環境と通信できないため、使用できません。
その際は、ローカルマシン上のDockerで動かすなど工夫が必要です。

機密情報などをどう保持するかは悩ましい

GitHub CodespacesであればActions同様にSecretsが使えるのですが、Dev Containersであればその良さを活かすことができないので何か他の方法を考えないといけないです。
イメージに近かったのは、Docker SecretsだったのですがSwarmが動いている必要がありそうだったので、今回のやりたいイメージとはちょっと大袈裟かな、と思ったので違いそうでした。
最終的には、リモートマシン上に持たせておいてDev Containersの設定でマウントする方法がありそうなので、これを試してみようと思っています。

これからは？

コンテナ間通信の部分で課題があったのですが知識不足なところがあったので、おそらく使い方の問題だろうと部分の改善をやっていきます。

Docker in Dockerな状態を解消

最初の頃はできないと思い込んでいたのでDocker in Dockerな状態で起動するようにしてしまっていたので、Dev Containersを立ち上げるときと同じ並びでDBコンテナやそれ以外のコンテナを立ち上げるように修正したいと思っています。

別々にした開発環境間の通信

バックエンドサーバーとフロントエンドサーバーを別々に開発環境として立ち上げているのですが、直接通信ができない状態でした。これもDocker in Dokerな状態で立ち上げていたので、直接通信がむずかしい状態になっていたのですが、フラットにできることで恐らくもっと簡単に解消できると思っています。

おわりに

色々と試行錯誤しながら2ヶ月くらい経っていましたが、今のところ使用を止めるほどの問題には遭遇していないので、このまま使い続けながら引き続き様子見てみたいと思います。
機密情報などをどのように保持させるかは少しやり方を悩んでいるくらいですが、それ以外は割とスムーズに使えているように思います。
またしばらく経った頃に経過報告としてブログにまとめられたらと思っています。