Back

ローカル開発におけるDev Containersの活用

ローカル開発におけるDev Containersの活用

おそらくこのような経験があるでしょう。新しい開発者がチームに加わり、2日後にはまだNodeのバージョン競合、不足している依存関係、他の全員のマシンでは動作するのに自分のマシンでは動作しない環境変数と格闘している。その間、実際のプロジェクトには手がつけられていません。

Dev Containersは、開発環境全体(ランタイム、ツール、拡張機能、設定)をコンテナにパッケージ化することで、すべてのマシンで同一に動作する環境を提供し、この問題を解決します。本記事では、Dev Containersが深いDockerの専門知識を必要とせずに、フロントエンドチームのために再現可能な開発環境を作成する方法を解説します。

重要なポイント

  • Dev Containersは、開発環境全体(ランタイム、ツール、拡張機能、設定)を再現可能なコード定義されたコンテナにパッケージ化します。
  • 単一のdevcontainer.jsonファイルが、長いセットアップドキュメントに取って代わり、「私のマシンでは動く」問題を解消します。
  • 事前構築されたイメージがほとんどのフロントエンドのニーズをカバーし、Docker Composeが複数サービスのセットアップを処理します。
  • containerEnvremoteEnv(およびcontainerUserremoteUser)の違いを理解することで、一般的な権限と設定のエラーを防ぐことができます。
  • Dev Containersは一貫性を提供しますが、不変性を提供するわけではありません。イメージのバージョンを固定し、定期的に設定をテストしてください。

Dev Containersが実際に行うこと

Dev Containersは、開発作業専用に設定されたDockerコンテナです。アプリケーションを実行する本番用コンテナとは異なり、Dev Containersは開発環境全体を実行します。エディタがコンテナに接続し、すべてのツールがその中で実行されます。

重要な洞察はシンプルです。セットアップ手順を文書化して全員が正しく従うことを期待する代わりに、環境をコードで定義します。開発者がプロジェクトを開くと、他の全員とまったく同じNodeバージョン、同じリンティングツール、同じエディタ拡張機能が得られます。

このコンテナ化されたローカル開発へのアプローチは、「私のマシンでは動く」問題を完全に解消します。devcontainer.jsonファイルが、プロジェクトの開発方法に関する唯一の信頼できる情報源となります。

理解すべき中核概念

devcontainer.jsonファイル

すべてのDev Container設定は、通常プロジェクトルートの.devcontainerフォルダに保存されるdevcontainer.jsonファイルから始まります。このファイルは、コンテナをビルドまたはプルする方法と、その中で何を設定するかをエディタに伝えます。

フロントエンドプロジェクトの最小限の設定は次のようになります。

{
  "name": "Frontend Dev Environment",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "forwardPorts": [3000],
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

この設定は、TypeScriptサポート付きの事前構築されたNode 20イメージをプルし、ホストブラウザから開発サーバーにアクセスできるようにポート3000を転送し、VS CodeにESLintとPrettier拡張機能を自動的にインストールします。

イメージ vs. Dockerfile

コンテナのベースを定義するには2つのオプションがあります。事前構築されたイメージを使用する(上記の例のように)方が簡単で高速です。ビルドするものがないため、コンテナが素早く起動します。Dockerfileを使用すると完全な制御が可能ですが、ビルド時間が追加されます。

ほとんどのフロントエンドプロジェクトでは、MicrosoftのDev Containerイメージリポジトリからの事前構築されたイメージがうまく機能します。カスタムDockerfileを必要とせずに特定のツールをインストールするモジュール式の追加機能であるFeaturesで拡張できます。

複雑なセットアップのためのDocker Compose

開発中にフロントエンドがバックエンドサービス(データベース、APIサーバー、Redisキャッシュ)を必要とする場合、Docker Compose統合により複数コンテナ環境を定義できます。devcontainer.jsonがComposeファイルを参照し、すべてのサービスが一緒に起動します。

{
  "name": "Full Stack Dev Environment",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace"
}

このセットアップでは、serviceプロパティがComposeファイル内のどのコンテナにエディタが接続すべきかを指定し、残りのサービス(データベース、キャッシュ、API)がその横で実行されます。

環境変数:containerEnv vs. remoteEnv

この区別は重要であり、混乱を引き起こします。containerEnvはコンテナの起動時に変数を設定し、すべてのプロセスで利用可能になります。remoteEnvはエディタが生成するプロセスに対してのみ変数を設定します。ビルドツールが必要とする変数にはcontainerEnvを使用し、エディタ固有の設定にはremoteEnvを使用してください。

{
  "containerEnv": {
    "NODE_ENV": "development",
    "API_URL": "http://localhost:4000"
  },
  "remoteEnv": {
    "EDITOR_THEME": "dark"
  }
}

同様に、containerUserはコンテナ内のプロセスを所有するユーザーを決定し、remoteUserはエディタが接続するユーザーを制御します。これらを間違えると、開発者を悩ませる権限エラーが発生します。ほとんどの場合、remoteUser"node"(Nodeベースのイメージの場合)に設定することで、生成されたファイルのroot所有権の問題を回避できます。

Dev Containersが保証しないこと

拡張機能のインストールとワークスペース設定は、リビルド間で完全に再現可能ではありません。拡張機能は更新され、一部の設定はローカル状態に依存します。イメージに組み込まれた設定も、更新されたベースイメージでリビルドすると変更される可能性があります。

Dev Containersが提供するのは一貫性であり、不変性ではないことを受け入れてください。イメージのバージョンを固定し(例えば、latestではなく特定のSHAダイジェストまたは日付付きタグを使用)、定期的に設定をテストしてください。

検討すべきトレードオフ

Dev Containersは起動時間を追加します。作業を開始する前にコンテナをビルドまたはプルする必要があります。イメージのためのディスクスペースを消費します。そして、Dockerfileを書くことがなくても、チームはDockerの概念に関する基本的な知識が必要です。

オンボーディングに数日かかり、環境のずれが定期的に問題を引き起こすチームにとって、これらのコストは些細なものです。シンプルなプロジェクトに取り組む単独の開発者にとっては、価値がないかもしれません。

注目すべき新しいワークフロー

チームは、Dev Container設定を通じてAIコーディングアシスタントやエージェントスタイルのサービスを統合することが増えています。コンテナは単なる開発環境ではなく、自動化されたツールがコードを操作する環境になります。このパターンは急速に進化していますが、基盤である環境をコードとして定義することは安定しています。

始め方

VS CodeがDev Containerの最もスムーズな体験を提供します。Docker Desktopをインストールし、Dev Containers拡張機能を追加し、コマンドパレットからDev Containers: Add Dev Container Configuration Filesを実行してください。スタックに合ったテンプレートを選択すれば、数分以内にコンテナで実行できます。

他のエディタもDev Containersをサポートしています。JetBrains IDE(IntelliJやWebStormなど)は組み込みのDev Containerサポートを提供し、オープンソースのDev Container CLIを使用すると、任意のターミナルまたはCIパイプラインからDev Containersを使用できます。

結論

Dev Containerのセットアップへの投資は、新しいチームメイトが3日目ではなく初日から貢献を始めた最初の時点で報われます。開発環境を単一のdevcontainer.jsonファイルでコードとして定義することで、脆弱なセットアップドキュメントを再現可能で共有可能な設定に置き換えます。トレードオフ(起動時間、ディスクスペース、コンテナの基本的な理解)は、環境のずれのデバッグに費やされる時間と比較すると控えめです。事前構築されたイメージから始め、チームが依存する拡張機能を追加し、そこから反復してください。

よくある質問

いいえ。ほとんどのフロントエンドプロジェクトでは、Docker Desktopがインストールされて実行されているだけで十分です。devcontainer.jsonファイルが設定を処理し、Microsoftの事前構築されたイメージがDockerfileを書く必要性を排除します。コンテナが何であるかの基本的な認識はトラブルシューティングに役立ちますが、始めるために深いDockerの専門知識は必要ありません。

はい。IntelliJやWebStormなどのJetBrains IDEには組み込みのDev Containerサポートがあります。また、任意のターミナルからDev Containersをビルドして実行できるオープンソースのDev Container CLIもあり、CIパイプラインやリモート開発ワークフローをサポートする他のエディタで使用できます。

特にmacOSとWindowsでは、ファイルがホストとコンテナ間で共有されるため、ファイルシステム操作がわずかに遅くなる場合があります。名前付きボリュームを使用するか、プロジェクトをコンテナファイルシステム内に保存することで、このオーバーヘッドを減らすことができます。CPUとメモリのパフォーマンスは、一般的にネイティブ開発と同等です。

はい。Dev ContainersはDocker Composeをサポートしており、複数コンテナ環境を定義できます。エディタは1つのコンテナに接続し、データベース、APIサーバー、キャッシュは別々のコンテナでその横で実行されます。プロジェクトを開くと、すべてのサービスが一緒に起動します。

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay