Zenn
🐋

VSCode Dev Containerが解決できる課題と基本的な概念

2024/05/12に公開
VS Code
devcontainer
tech

対象読者

  • ジャンル問わず開発者全般
  • 言語は問わないが開発経験があること
  • VSCodeのExtensionの概念を理解していること
  • Docker Containerの利用経験があること

Dev ContainersはWeb Frontend/Backend/Tool作成全てにおいて便利なユースケースとして利用可能です。開発言語は問いません。何かしらの開発経験があれば恩恵を受けることができます。しかし、ベースの知識としてVSCodeのExetnsionの利用方法や概念は必須となります。また、Docker Containerを基礎として提供されている機能になるため、DockerfileであったりBuildの概念を理解していないと、自分好みの環境にカスタマイズするときに困ることになるため、Dockerの知識は必須となります。

Dev Containersが解決できる主な課題

何かしらの理由により複数（人）の環境で開発をしなければいけない状況の時に、一般的に発生する多くの課題があります。

開発環境の作り方をREADMEもしくは別のDocに書かないといけない

誰もが一度は見たことのあるDocumentだと思います。Pythonを入れて、このツールを入れて、このツールを入れて・・・というDocumentです。現実的には、これらのDocumentがメンテナンスがされ続けるケースは多くありません。そのため、Documentを渡したものの、開発環境が独力では整備することができないため、フォローの稼働が必要になったりすることが多いです。

また、何らかの理由で開発環境を複製しなければいけないタイミングがプロジェクトの中では発生するのですが、この時にも同じ問題に直面することになります。最悪のケースでは、開発環境を複製できれば開発効率が大きく向上するにも関わらず、複製の手間を考慮して複製することを諦めてしまうこともあります。結果として、開発環境を共用することで想定外の事象が発生し、効率が下がるようなことも珍しくありません。

開発環境がチーム内で統一化されない

１つの開発のチーム中でも、このPJではPoetryが使われているのに他のPJではpipで管理されているといったチーム内でツールが乱立することにより品質・効率が統一化されない状況が発生します。Dev Conrainersを使うと必然的にDev ContainerのTemplateに相当するものが作られるため、チーム内でのツールの統一化の推進が可能です。また、Dev Containerでツールをインストールすることで、メンバーにツールをインストールしてもらう手間とDocumentを用意する手間も省力化することができます。

さらに、VSCodeのExtensionも統一化することができます。VSCodeの主要言語のExtensionにはいくつか派閥が存在していますが、派閥があること自体は好みの問題もあり良いと思うのですが、開発者同士が思っているExtensionが実は違うものだったりすることでミスコミュニケーションが産まれるケースがあります。また、開発効率をあげるExtensionがうまく共有されないというケースもあります。

Dev Containersとは

上述の課題を解決することのできる、VSCodeのExtensionとして提供される機能です。Dev Containersが正式名称であり、本記事では機能についてはDev Containersと表記し、Dev Contaienrsを用いて作成されるContainer自身をDev Containerと記載することにします。

Dev Containersが提供する概念は公式の下記の図が最もわかりやすいです。

alt text

Local OSのVSCodeは単純なFrontendのClientとして動作させ、VSCodeの開発に関する機能はContainerの中にVSCodeServerとしてBackendとして動作させることで、Containerの中で実現することでLocal OSは画面表示のみの利用とするアーキテクチャで実現しています。

VSCodeにはVSCodeServerという機能が存在しており、RemoteSSH等でも利用されています。Dev ContainersはVSCodeServerの機能を利用したアーキテクチャであり、Simpleな構成となっている。VSCodeServerについてはの詳細は公式Documentを参照してください。

devcontainer.json

Dev Containerの環境は./devcontainerというディレクトリがプロジェクトルートの中に存在する形となり、このディレクトリの中のdevcontainer.jsonに定義されます。

Dockerfileを使う場合やcomposeを使う場合もこのディレクトリの中に配置されることとなりますが、本記事では具体的な書き方までは触れずに後の記事で説明をすることにします。

詳細は公式Documentを参照してください。

Dev ContainerとProduction ContainerのLayer分離

公式に下記の図がありますが、この図が最もイメージがつきやすく、この図を参照したLayer分離でdevcontainer.jsonを作っていくことになります。

alt text

要約するとDev Containerとして準備されるべき領域は今まで開発環境のOSで用意されていた領域になり、開発環境のOSにインストールされて機能をDev Containerの中にインストールしていく形となります。

Compilers,SDKs,libraries,build tools, and utiliiesと記載がある部分は、Python等のInterpreterやJava/Go等のCompilerおよびそれらのLibraryが該当します。対象の帯がProduction Containerに存在していない理由は、Java/Go等はBuildした後の実行環境のみがProduction Layerに存在すれば良いため、Multi-stage buildsを意識した構成になっていると考えられます。Python等のInterpreter言語の場合は構成が異なり、ProductionでもInterpreterが必要になるため、対象の帯はProduction Containerまで伸びることになります。

Multi-stage buildsについては公式Documentを参照してください

Debuggeres, OS utilities,and CLIsおよびPersonalization,productivity toolsと記載がある部分は、開発環境に必要なDebugger等のツールとなります。これらは開発を便利にするDebbugerツールや個人的に利用したい便利ツールなどが該当するため、Production Containerには必要ないためDev Containerの中にインストールすべきツールとなっています。Dev Containerの中にInner LoopとOuter Loopが存在しているが、ここは厳密にContainerが別れるかは環境や思想によるため、Inner Loopにのみインストールするかはチームやプロジェクトの方針によって異なってくると考えています。また、特に個人用のツールに関しては個人の好みで実装されるため、Dev Containerに入れるべきかは議論が必要になる部分です。

まとめ

Dev Contaienrsが解決できる課題と、Dev Containersの概念を説明しました。
この記事では具体的な機能や書き方についてまだは触れていませんが、以降の記事で詳細について追記をしていきたいと考えています。

Discussion