開発環境をコンテナで配る - devcontainer

複数人で 1 つのプロジェクトを触るとき、「Node のバージョンが違う」「手元だけ動く」「新メンバーの環境構築に 1 日かかる」といった話は珍しくありません。

Dev Containers は、開発に必要なランタイム・CLI・エディタ設定・拡張機能をすべてコンテナ定義に書き出し、リポジトリに含めてしまうアプローチです。

リポジトリを開いて「コンテナで開く」を選ぶだけで、Docker が定義どおりのイメージをビルドし、VS Code がそのコンテナ内で動くサーバーに接続します。

ローカル OS には Node も Python も入れないまま、コンテナ側で npm run dev が走る、という状態になります。

Dev Containers は「VS Code のリモート開発」機能の一形態です。

ローカルの VS Code は UI 層だけを担当し、言語サーバーやターミナル、デバッガはコンテナ側で動く VS Code Server に入ります。

[Host OS]
  ├─ VS Code (UI) ─── 接続 ──┐
  └─ Docker Engine           │
       └─ devcontainer (Linux)
            ├─ VS Code Server
            ├─ Node / Python / etc.
            └─ source tree (bind mount or volume)

ソースコードはホスト側をそのまま bind mount する方式と、コンテナ内のボリュームにクローンする方式があります。

前者は編集がそのままホストのファイルに反映されて分かりやすく、後者は IO が速くファイル権限問題が出にくいという特徴があります。

devcontainer.json は、ローカル Docker でも GitHub Codespaces でも同じファイルが使われます。

違いは「誰のマシンでコンテナを動かすか」だけで、ローカルでは手元の Docker Engine、Codespaces ではクラウド上の VM 上に立ち上がります。

つまり 1 つの定義を書けば、個人の Mac でも、Windows + WSL2 でも、Codespaces のブラウザでも、同じ開発体験が得られます。

チーム全員に Docker Desktop を入れさせたくない場合の逃げ道として Codespaces を選ぶ、といった使い方もできます。

場面	判断	理由
ランタイムが複数の言語・バージョンで混在	向く	個人の PATH を汚さず切り替えられる
オンボーディングに時間がかかる	向く	README の「まずこれを入れろ」が消える
DB / Redis / MinIO などを起動する	向く	docker-compose.yml と組み合わせて一発で立つ
GPU やカーネルモジュールが必須	注意	GPU 対応には別途設定、Linux ホスト前提のケースあり
ネイティブの macOS/Windows GUI アプリ開発	向かない	そもそもコンテナ外で動かす必要がある

「動く開発環境を配布する」ユースケースには強いですが、コンテナ化できないデスクトップアプリや特殊なハードウェア連携は通常のローカル開発に倒した方が無理がありません。