コンテナー内での開発

Visual Studio Code Dev Containers 拡張機能を使用すると、コンテナーをフル機能の開発環境として利用できます。コンテナー内（またはコンテナーにマウントされた）任意のフォルダーを開き、Visual Studio Code の全機能セットを活用できます。プロジェクト内の devcontainer.json ファイルは、適切に定義されたツールとランタイムスタックを持つ開発コンテナーにアクセスする（または作成する）方法を VS Code に指示します。このコンテナーは、アプリケーションの実行や、コードベースの作業に必要なツール、ライブラリ、ランタイムの分離に使用できます。

ワークスペースファイルは、ローカルファイルシステムからマウントされるか、コンテナー内にコピーまたはクローンされます。拡張機能はコンテナー内にインストールされて実行され、ツール、プラットフォーム、ファイルシステムにフルアクセスできます。つまり、別のコンテナーに接続するだけで、開発環境全体をシームレスに切り替えることができます。

Container Architecture

これにより、VS Code は、ツール（またはコード）がどこにあるかに関係なく、完全な IntelliSense（補完）、コードナビゲーション、デバッグを含むローカル品質の開発エクスペリエンスを提供できます。

Dev Containers 拡張機能は、主に 2 つの動作モデルをサポートしています

コンテナーをフルタイムの開発環境として使用できます
実行中のコンテナーを検査するためにアタッチできます。

注: Dev Containers 拡張機能は、オープンな Dev Containers 仕様をサポートしており、誰でもあらゆるツールで一貫した開発環境を構成できるようになります。詳細は、開発コンテナーの FAQ および仕様のサイト containers.dev を参照してください。

はじめに

注: 開発コンテナーをすぐに使い始める方法は、入門用の開発コンテナーチュートリアルで学ぶことができます。

システム要件

ローカル / リモートホスト

Dev Containers 拡張機能で Docker を使用する方法には、以下のようなものがあります

Dockerがローカルにインストールされている。
リモート環境にインストールされた Docker。
ローカルまたはリモートにインストールされた、その他の Docker 準拠 CLI。
- 他の CLI でも動作する可能性がありますが、公式にはサポートされていません。なお、Kubernetes クラスターへのアタッチには、適切に構成された kubectl CLI のみが必要です。

詳細は代替 Docker オプションのドキュメントを参照してください。

ローカルまたはリモートホストで Docker を構成する具体的な方法は以下の通りです

Windows: Windows 10 Pro/Enterprise 上の Docker Desktop 2.0+。Windows 10 Home (2004+) の場合は Docker Desktop 2.3+ と WSL 2 バックエンドが必要です。(Docker Toolbox はサポートされていません。Windows コンテナーイメージはサポートされていません。)
macOS: Docker Desktop 2.0+。
Linux: Docker CE/EE 18.06+ および Docker Compose 1.21+。(Ubuntu の snap パッケージはサポートされていません。)
リモートホスト: 1 GB の RAM が必要ですが、少なくとも 2 GB の RAM と 2 コア CPU を推奨します。

コンテナー:

x86_64 / ARMv7l (AArch32) / ARMv8l (AArch64) Debian 9+, Ubuntu 16.04+, CentOS / RHEL 7+
x86_64 Alpine Linux 3.9+

その他の glibc ベースの Linux コンテナーも、必要な Linux の前提条件を満たしていれば動作する可能性があります。

インストール

開始するには、以下の手順に従ってください

以下のいずれかのパス、またはリモートホスト上の Docker や Docker 準拠 CLI といった代替の Docker オプションを使用して、お使いのオペレーティングシステム用に Docker をインストールして構成します。

Windows / macOS:
1. Docker Desktop for Windows/Mac をインストールします。
2. Windows で WSL 2 を使用している場合、WSL 2 バックエンドが有効であることを確認します。Docker タスクバーアイテムを右クリックし、Settings を選択します。Use the WSL 2 based engine にチェックを入れ、Resources > WSL Integration でお使いのディストリビューションが有効になっていることを確認します。
3. WSL 2 バックエンドを使用していない場合は、Docker タスクバーアイテムを右クリックして Settings を選択し、Resources > File Sharing を更新して、ソースコードが保管されている場所を追加します。トラブルシューティングについては、ヒントとコツを参照してください。
Linux:
1. お使いのディストリビューション用の Docker CE/EE の公式インストール手順に従ってください。Docker Compose を使用する場合は、Docker Compose の指示にも従ってください。
2. ターミナルで sudo usermod -aG docker $USER を実行して、ユーザーを docker グループに追加します。
3. 変更を有効にするために、一度サインアウトしてから再度サインインします。
Visual Studio Code または Visual Studio Code Insiders をインストールします。
Dev Containers 拡張機能をインストールします。VS Code で他のリモート拡張機能を使用する予定がある場合は、Remote Development 拡張機能パックをインストールすることをお勧めします。

Git を使用していますか？

考慮すべき 2 つのヒントがあります

Windows のローカル環境とコンテナー内の両方で同じリポジトリを操作する場合は、一貫した改行コードを設定してください。詳細はヒントとコツを参照してください。
Git 資格情報マネージャーを使用してクローンする場合、コンテナーはすでに資格情報にアクセスできるはずです。SSH キーを使用している場合は、それらを共有するように設定することもできます。詳細はコンテナーとの Git 資格情報の共有を参照してください。

クイックスタートの選択

このドキュメントには 3 つのクイックスタートが含まれています。ワークフローと興味に最も適したものから始めることをお勧めします

クイックサンプルリポジトリで開発コンテナーを試してみたいですか？クイックスタート 1: 開発コンテナーを試すを確認してください。
既存のローカルにクローンされたプロジェクトのいずれかに開発コンテナーを追加したいですか？クイックスタート 2: 既存のフォルダーをコンテナーで開くを確認してください。
ローカルの作業に影響を与えずに、PR のレビューやブランチの調査などのために、リポジトリの分離されたコピーで作業したいですか？クイックスタート 3: Git リポジトリまたは PR を分離されたコンテナーボリュームで開くを確認してください。

クイックスタート: 開発コンテナーを試す

最も簡単な始め方は、サンプル開発コンテナーのいずれかを試すことです。コンテナーチュートリアルでは、Docker と Dev Containers 拡張機能のセットアップを順を追って説明し、サンプルを選択できます。

Select a sample from the list

注: すでに VS Code と Docker がインストールされている場合は、開発コンテナーで開くを使用できます。これの詳細やリポジトリへの追加方法は、開発コンテナー作成ガイドで詳しく説明しています。

クイックスタート: 既存のフォルダーをコンテナーで開く

このクイックスタートでは、ファイルシステム上の既存のソースコードを使用して、フルタイムの開発環境として使用する既存プロジェクトの開発コンテナーをセットアップする方法を説明します。以下の手順に従ってください

VS Code を起動し、コマンドパレット (F1) またはステータスバーのクイックアクションアイテムから Dev Containers: Open Folder in Container... (コンテナーでフォルダーを開く...) コマンドを実行し、コンテナーをセットアップするプロジェクトフォルダーを選択します。

ヒント: フォルダーを開く前にコンテナーの内容や設定を編集したい場合は、代わりに Dev Containers: Add Dev Container Configuration Files... (開発コンテナー構成ファイルの追加...) を実行できます。
次に、開発コンテナーの開始点を選択します。フィルター可能なリストからベースとなる Dev Container Template (開発コンテナーテンプレート) を選択するか、選択したフォルダーに既存の Dockerfile または Docker Compose ファイルがある場合はそれを使用できます。

注意: Alpine Linuxコンテナを使用する場合、ネイティブコード内のglibc依存関係が原因で、一部の拡張機能が動作しない場合があります。

リストは、開いたフォルダーの内容に基づいて自動的にソートされます。

追加の Features (機能) で開発コンテナーをカスタマイズできる場合があります。これについては以下で詳しく説明します。

表示される開発コンテナーテンプレートは、Dev Container Specification の一部であるファーストパーティおよびコミュニティインデックスから提供されています。私たちは仕様の一部として、devcontainers/templates リポジトリで一連のテンプレートをホストしています。そのリポジトリの src フォルダーをブラウズして、各テンプレートの内容を確認できます。

また、dev container CLI を使用して、独自に開発コンテナーテンプレートを公開および配布することも可能です。
コンテナーの開始点を選択した後、VS Code は開発コンテナー構成ファイル (.devcontainer/devcontainer.json) をプロジェクトに追加します。
VS Code ウィンドウがリロードされ、開発コンテナーのビルドが開始されます。進行状況の通知でステータスが更新されます。開発コンテナーのビルドが必要なのは最初の一回だけです。最初のビルドが成功した後は、フォルダーを開くのがずっと早くなります。
ビルドが完了すると、VS Code は自動的にコンテナーに接続します。

これで、プロジェクトをローカルで開いたときと同じように、VS Code でプロジェクトを操作できます。今後、プロジェクトフォルダーを開くと、VS Code は自動的に開発コンテナー構成を認識して再利用します。

ヒント: リモート Docker ホストを使用したいですか？情報の詳細は、リモート SSH ホスト上のフォルダーをコンテナーで開くセクションを参照してください。

ローカルファイルシステムをコンテナーにバインドマウントするこのアプローチは便利ですが、Windows や macOS ではパフォーマンスのオーバーヘッドが発生します。ディスクパフォーマンスを向上させるために適用できるいくつかのテクニックがあります。あるいは、代わりに分離されたコンテナーボリュームを使用してリポジトリをコンテナーで開くこともできます。

Windows で WSL 2 フォルダーをコンテナーで開く

Windows Subsystem for Linux v2 (WSL 2) を使用しており、Docker Desktop の WSL 2 バックエンドを有効にしている場合は、WSL 内に保存されているソースコードを操作できます。

WSL 2 エンジンが有効になったら、以下のいずれかを行います

WSL 拡張機能を使用してすでに開いているフォルダーから、Dev Containers: Reopen in Container (コンテナーで再度開く) コマンドを使用します。
コマンドパレット (F1) から Dev Containers: Open Folder in Container... (コンテナーでフォルダーを開く...) を選択し、ローカルの \\wsl$ 共有（Windows 側から）を使用して WSL フォルダーを選択します。

クイックスタートの残りの部分はそのまま適用されます。WSL 拡張機能の詳細は、そのドキュメントを参照してください。

リモート SSH ホスト上のフォルダーをコンテナーで開く

Linux または macOS の SSH ホストを使用している場合は、Remote - SSH 拡張機能と Dev Containers 拡張機能を一緒に使用できます。ローカルに Docker クライアントをインストールする必要さえありません。

これを行うには

Remote - SSH 拡張機能のインストールと SSH ホストのセットアップ手順に従います。
オプション: SSH キーベース認証をサーバーに設定しておくと、パスワードを複数回入力する必要がなくなります。
SSH ホストに Docker をインストールします。ローカルに Docker をインストールする必要はありません。
Remote - SSH 拡張機能のクイックスタートに従ってホストに接続し、そこでフォルダーを開きます。
コマンドパレット (F1、⇧⌘P (Windows、Linux Ctrl+Shift+P)) から Dev Containers: Reopen in Container コマンドを使用します。

Dev Containers クックスタートの残りの部分はそのまま適用されます。Remote - SSH 拡張機能の詳細は、そのドキュメントを参照してください。また、このモデルがニーズに合わない場合の他のオプションについては、リモート Docker ホストでの開発の記事も参照してください。

リモートトンネルホスト上のフォルダーをコンテナーで開く

Remote - Tunnels 拡張機能と Dev Containers 拡張機能を組み合わせて、リモートホスト上のフォルダーをコンテナー内で開くことができます。ローカルに Docker クライアントをインストールする必要はありません。これは上記の SSH ホストのシナリオに似ていますが、代わりに Remote - Tunnels を使用します。

これを行うには

Remote - Tunnels 拡張機能の入門手順に従います。
トンネルホストに Docker をインストールします。ローカルに Docker をインストールする必要はありません。
Remote - Tunnels 拡張機能の手順に従ってトンネルホストに接続し、そこでフォルダーを開きます。
コマンドパレット (F1、⇧⌘P (Windows、Linux Ctrl+Shift+P)) から Dev Containers: Reopen in Container コマンドを使用します。

Dev Containers クックスタートの残りの部分はそのまま適用されます。Remote - Tunnels 拡張機能の詳細は、そのドキュメントを参照してください。また、このモデルがニーズに合わない場合の他のオプションについては、リモート Docker ホストでの開発の記事も参照してください。

既存のワークスペースをコンテナーで開く

ワークスペースが、.code-workspace ファイルがあるフォルダーのサブフォルダー（またはそのフォルダー自体）への相対パスのみを参照している場合、同様のプロセスに従って VS Code マルチルートワークスペースを単一のコンテナーで開くこともできます。

以下のいずれかを行います

Dev Containers: Open Workspace in Container... (コンテナーでワークスペースを開く...) コマンドを使用します。
コンテナー内で .code-workspace ファイルを含むフォルダーを開いたら、File > Open Workspace... (ファイル > ワークスペースを開く...) を使用します。

接続後、内容を簡単に編集できるように、.devcontainer フォルダーをワークスペースに追加することをお勧めします（まだ表示されていない場合）。

また、同じ VS Code ウィンドウ内の同じワークスペースに対して複数のコンテナーを使用することはできませんが、別々のウィンドウから Docker Compose で管理された複数のコンテナーを同時に使用することは可能です。

クイックスタート: Git リポジトリまたは GitHub PR を分離されたコンテナーボリュームで開く

ローカルにクローンされたリポジトリをコンテナーで開くこともできますが、作業に影響を与えずに PR レビューを行ったり別のブランチを調査したりするために、リポジトリの分離されたコピーを使用したい場合があります。

リポジトリコンテナーは、ローカルファイルシステムにバインドする代わりに、分離されたローカル Docker ボリュームを使用します。ファイルツリーを汚さないことに加えて、ローカルボリュームには Windows や macOS でのパフォーマンスが向上するという利点もあります。（他のシナリオでこれらのタイプのボリュームを使用する方法については、構成の詳細に関する記事ディスクパフォーマンスの向上を参照してください。）

例えば、以下の手順に従って「試用 (try)」リポジトリの 1 つをリポジトリコンテナーで開きます

VS Code を起動し、コマンドパレット (F1) から Dev Containers: Clone Repository in Container Volume... (コンテナーボリュームでリポジトリをクローン...) を実行します。
表示される入力ボックスに microsoft/vscode-remote-try-node (または他の「試用」リポジトリの 1 つ)、Git URI、GitHub ブランチ URL、または GitHub PR URL を入力し、Enter を押します。

ヒント: プライベートリポジトリを選択する場合は、資格情報マネージャーをセットアップするか、SSH エージェントに SSH キーを追加することをお勧めします。詳細はコンテナーとの Git 資格情報の共有を参照してください。
リポジトリに .devcontainer/devcontainer.json ファイルが含まれていない場合は、フィルター可能なリストから開始点を選択するか、既存の Dockerfile または Docker Compose ファイル (存在する場合) を選択するよう求められます。

注意: Alpine Linuxコンテナを使用する場合、ネイティブコード内のglibc依存関係が原因で、一部の拡張機能が動作しない場合があります。

リストは、開いたフォルダーの内容に基づいて自動的にソートされます。表示される開発コンテナーテンプレートは、Dev Container Specification の一部であるファーストパーティおよびコミュニティインデックスから提供されています。私たちは仕様の一部として、devcontainers/templates リポジトリで一連のテンプレートをホストしています。そのリポジトリの src フォルダーをブラウズして、各テンプレートの内容を確認できます。
VS Code ウィンドウ（インスタンス）がリロードされ、ソースコードがクローンされ、開発コンテナーのビルドが開始されます。進行状況の通知でステータスが更新されます。

手順 2 で GitHub のプルリクエスト URL を貼り付けた場合、PR が自動的にチェックアウトされ、GitHub Pull Requests 拡張機能がコンテナーにインストールされます。この拡張機能は、PR エクスプローラー、インラインでの PR コメント操作、ステータスバーの表示など、PR 関連の追加機能を提供します。
ビルドが完了すると、VS Code は自動的にコンテナーに接続します。これで、コードをローカルにクローンした場合と同じように、この独立した環境でリポジトリのソースコードを操作できます。

Docker ビルドエラーなどでコンテナーの起動に失敗した場合、表示されるダイアログで Reopen in Recovery Container (リカバリコンテナーで再度開く) を選択すると、Dockerfile などの内容を編集できる「リカバリコンテナー」に入ることができます。これにより、クローンされたリポジトリを含む Docker ボリュームが最小限のコンテナーで開かれ、作成ログが表示されます。修正が終わったら、Reopen in Container (コンテナーで再度開く) を使用して再試行してください。

ヒント: リモート Docker ホストを使用したいですか？情報の詳細は、リモート SSH ホスト上のフォルダーをコンテナーで開くセクションを参照してください。

ワークスペースの信頼

Visual Studio Code はセキュリティを重視しており、ソースや作成者に関わらず、コードを安全に閲覧・編集できるよう支援したいと考えています。ワークスペースの信頼機能を使用すると、プロジェクトフォルダーが自動的なコード実行を許可するか制限するかを決定できます。

Dev Containers 拡張機能は「ワークスペースの信頼」を採用しています。ソースコードを開いて操作する方法に応じて、編集または実行しているコードを信頼するかどうかを尋ねるプロンプトが様々なタイミングで表示されます。

コンテナーでフォルダーを再度開く

既存のプロジェクト用に開発コンテナーをセットアップするには、ローカル（または WSL）フォルダーを信頼する必要があります。ウィンドウがリロードされる前に、ローカル（または WSL）フォルダーを信頼するかどうか尋ねられます。

このフローにはいくつか例外があります

「最近使用した項目」をクリックした場合。
Open Folder in Container コマンドを使用する場合、信頼がまだ与えられていなければ、ウィンドウのリロード後に信頼を求めるメッセージが表示されます。

既存のコンテナーにアタッチ

既存のコンテナーにアタッチする場合、アタッチすることはコンテナーを信頼することを意味するという確認を求められます。これは一度だけ確認されます。

Workspace trust prompt when attaching to container

ボリュームでリポジトリをクローン

コンテナーボリュームでリポジトリをクローンする場合、リポジトリをクローンすることはリポジトリを信頼することを意味するという確認を求められます。これは一度だけ確認されます。

Workspace trust prompt when cloning in container volume

ボリュームを検査

ボリュームの検査は制限付きモードで開始され、コンテナー内のフォルダーを信頼できます。

リモートで実行されている Docker デーモン

これは、Docker デーモンが実行されているマシンを信頼することを意味します。追加の確認プロンプトはありません（上記のローカル/WSL ケースでリストされたもののみです）。

devcontainer.json ファイルの作成

VS Code のコンテナー構成は devcontainer.json ファイルに保存されます。このファイルはデバッグ構成用の launch.json ファイルに似ていますが、代わりに開発コンテナーを起動（またはアタッチ）するために使用されます。また、コンテナーの実行後にインストールする拡張機能や、環境を準備するための作成後コマンドを指定することもできます。開発コンテナー構成は、.devcontainer/devcontainer.json の下に配置されるか、プロジェクトのルートに .devcontainer.json ファイル（ドットプレフィックスに注意）として保存されます。

コマンドパレット (F1) から Dev Containers: Add Dev Container Configuration Files... (開発コンテナー構成ファイルの追加...) コマンドを選択すると、開始点として必要なファイルがプロジェクトに追加され、ニーズに合わせてさらにカスタマイズできます。このコマンドを使用すると、フォルダーの内容に基づいたリストから定義済みのコンテナー構成を選択したり、既存の Dockerfile を再利用したり、既存の Docker Compose ファイルを再利用したりできます。

Select a node Dev Container Template

手動で devcontainer.json を作成し、任意のイメージ、Dockerfile、または Docker Compose ファイルのセットを開始点として使用することもできます。以下は、ビルド済みの開発コンテナーイメージの 1 つを使用した簡単な例です

{
  "image": "mcr.microsoft.com/devcontainers/typescript-node",
  "forwardPorts": [3000],
  "customizations": {
    // Configure properties specific to VS Code.
    "vscode": {
      // Add the IDs of extensions you want installed when the container is created.
      "extensions": ["streetsidesoftware.code-spell-checker"]
    }
  }
}

注: ベースイメージの内容に基づいて、追加の構成がすでにコンテナーに追加されます。例えば、上の例では streetsidesoftware.code-spell-checker 拡張機能を追加していますが、mcr.microsoft.com/devcontainers/typescript-node の一部であるため、コンテナーには "dbaeumer.vscode-eslint" も含まれます。これは devcontainer.json を使用して事前ビルドする際に自動的に行われます。詳細は事前ビルドのセクションを参照してください。

devcontainer.json ファイルの作成に関する詳細は、開発コンテナーの作成を参照してください。

開発コンテナーの Features (機能)

開発コンテナーの "Features (機能)" は、インストールコードと開発コンテナー構成を自己完結型にした、共有可能なユニットです。この名前は、それらを参照することで、あなたや共同作業者が使用するツール、ランタイム、ライブラリの「機能」を開発コンテナーに迅速かつ簡単に追加できるというアイデアに由来しています。

Dev Containers: Add Dev Container Configuration Files を使用すると、Git や Azure CLI のインストールなど、既存の開発コンテナー構成をカスタマイズするためのスクリプトのリストが表示されます

Dev container Features list drop down

コンテナーを再ビルドして再度開くと、選択した Features が devcontainer.json で利用可能になります

"features": {
    "ghcr.io/devcontainers/features/github-cli:1": {
        "version": "latest"
    }
}

devcontainer.json の "features" プロパティを直接編集する際、IntelliSense が機能します

Intellisense when modifying terraform Feature

Dev Containers: Configure Container Features (コンテナーの機能の構成) コマンドを使用すると、既存の構成を更新できます。

VS Code UI で提供される Features は、現在、中央のインデックスから取得されており、あなたも貢献することができます。現在のリストについては Dev Containers 仕様サイトを参照し、Features を公開および配布する方法を学んでください。

「常にインストールされる」Features

開発コンテナーに拡張機能を常にインストールするよう設定できるのと同様に、 dev.containers.defaultFeatures VS Code で開く VS Code Insiders で開くユーザー設定を使用して、常にインストールしたい Features を設定できます。

"dev.containers.defaultFeatures": {
    "ghcr.io/devcontainers/features/github-cli:1": {}
},

独自の Feature の作成

独自の開発コンテナー Feature を作成して公開するのも簡単です。公開された Features は、サポートされているパブリックまたはプライベートなコンテナーレジストリから OCI アーティファクトとして保存・共有できます。現在公開されている Features のリストは containers.dev で確認できます。

Feature は、少なくとも devcontainer-feature.json と install.sh エントリポイントスクリプトを含むフォルダー内の自己完結したエンティティです

+-- feature
|    +-- devcontainer-feature.json
|    +-- install.sh
|    +-- (other files)

独自のパブリックまたはプライベートな Features を公開するために dev container CLI を使用する手順については、feature/starter リポジトリを確認してください。

Features の仕様と配布

Features は、オープンソースの Development Containers Specification の主要な部分です。Features がどのように機能するか、およびその配布についての詳細情報を確認できます。

開発コンテナーイメージの事前ビルド

プロジェクトを開発コンテナーで開くたびにコンテナーイメージを作成・ビルドするのではなく、必要なツールを含んだイメージを事前ビルドしておくことをお勧めします。事前ビルドされたイメージを使用すると、コンテナーの起動が速くなり、構成が簡素化され、特定のバージョンのツールに固定できるため、サプライチェーンセキュリティが向上し、潜在的な破損を回避できます。GitHub Actions のような DevOps または継続的インテグレーション (CI) サービスを使用してビルドをスケジュールすることで、イメージの事前ビルドを自動化できます。

さらに良いことに、事前ビルドされたイメージには開発コンテナーのメタデータを含めることができるため、イメージを参照すると設定が自動的に引き継がれます。

開発コンテナー Features を含む、Dev Containers 拡張機能の最新機能と同期し続けるために、Dev Container CLI (または GitHub Action のような仕様をサポートするユーティリティ) を使用してイメージを事前ビルドすることをお勧めします。イメージをビルドしたら、コンテナーレジストリ (Azure Container Registry、GitHub Container Registry、または Docker Hub など) にプッシュして、直接参照できます。

ワークフローで開発コンテナーを再利用しやすくするために、devcontainers/ci リポジトリの GitHub Action を使用できます。

詳細は、イメージの事前ビルドに関する dev container CLI の記事を参照してください。

メタデータの継承

イメージラベルを介して、開発コンテナーの構成と Feature メタデータを事前ビルドされたイメージに含めることができます。これにより、イメージが直接参照されるか、参照された Dockerfile の FROM で、あるいは Docker Compose ファイルで参照されるかに関係なく、これらの設定が自動的に取得されるため、イメージが自己完結型になります。これは、開発コンテナーの構成とイメージの内容が同期しなくなるのを防ぐのに役立ち、単純なイメージ参照を通じて同じ構成のアップデートを複数のリポジトリにプッシュできるようにします。

このメタデータラベルは、Dev Container CLI (または GitHub Action や Azure DevOps タスクのような仕様をサポートするユーティリティ) を使用して事前ビルドする際に自動的に追加され、devcontainer.json と参照されている開発コンテナー Features からの設定が含まれます。

これにより、イメージの事前ビルドに使用する別途のより複雑な devcontainer.json と、1 つ以上のリポジトリにある劇的に簡素化されたものを使い分けることができます。イメージの内容は、コンテナーを作成する際にこの簡素化された devcontainer.json の内容とマージされます（マージロジックについては仕様を参照してください）。しかし、最も単純な形では、設定を有効にするために devcontainer.json でイメージを直接参照するだけで済みます

{
  "image": "mcr.microsoft.com/devcontainers/go:1"
}

なお、代わりに手動でイメージラベルにメタデータを追加することも選択できます。これらのプロパティは、ビルドに Dev Container CLI を使用しなかった場合でも取得されます（CLI を使用した場合は CLI によって更新されます）。例えば、この Dockerfile スニペットを考えてみましょう

LABEL devcontainer.metadata='[{ \
  "capAdd": [ "SYS_PTRACE" ], \
  "remoteUser": "devcontainer", \
  "postCreateCommand": "yarn install" \
}]'

ボリュームの検査

検査したり変更を加えたりしたい Docker 名前付きボリュームを使用している状況に遭遇することがあります。devcontainer.json ファイルを作成または変更することなく、VS Code を使用してこれらの内容を操作できます。コマンドパレット (F1) から Dev Containers: Explore a Volume in a Dev Container... (開発コンテナーでボリュームを探索...) を選択してください。

リモートエクスプローラーでボリュームを検査することもできます。ドロップダウンで「コンテナー」が選択されていることを確認すると、Dev Volumes セクションが表示されます。ボリュームを右クリックして、ボリュームが作成された日時、どのリポジトリがクローンされたか、マウントポイントなどの作成情報を検査できます。また、それを開発コンテナーで探索することもできます。

Right-click dev volumes in Remote Explorer

Container Tools 拡張機能がインストールされている場合は、Container Explorer の Volumes セクションでボリュームを右クリックし、Explore in a Development Container (開発コンテナーで探索) を選択できます。

Explore in dev container in Container Tools context menu

拡張機能の管理

VS Code は、ローカルの UI / クライアント側、またはコンテナー内のいずれかの場所で拡張機能を実行します。テーマやスニペットのように VS Code の UI に影響を与える拡張機能はローカルにインストールされますが、ほとんどの拡張機能は特定のコンテナー内に常駐します。これにより、特定のタスクに必要な拡張機能のみをコンテナーにインストールし、新しいコンテナーに接続するだけでツールチェーン全体をシームレスに切り替えることができます。

「拡張機能」ビューから拡張機能をインストールすると、正しい場所に自動的にインストールされます。拡張機能がどこにインストールされているかは、カテゴリのグループ化に基づいて判断できます。Local - Installed (ローカル - インストール済み) カテゴリと、お使いのコンテナー用のカテゴリがあります。

Workspace Extension Category

Local Extension Category

注: 拡張機能の作者で、拡張機能が正しく動作しない、または間違った場所にインストールされる場合は、詳細についてリモート開発のサポートを参照してください。

実際にはリモートで実行する必要があるローカル拡張機能は、Local - Installed カテゴリに Disabled (無効) として表示されます。Install を選択して、リモートホストに拡張機能をインストールしてください。

Disabled Extensions w/Install Button

「拡張機能」ビューに移動し、Local - Installed タイトルバーの右側にあるクラウドボタンを使用して Install Local Extensions in Dev Container: {Name} (開発コンテナーにローカル拡張機能をインストール) を選択することで、ローカルにインストールされているすべての拡張機能を開発コンテナー内にインストールすることもできます。これにより、コンテナーにインストールするローカル拡張機能を選択できるドロップダウンが表示されます。

Install all extensions

ただし、一部の拡張機能では、コンテナーに追加のソフトウェアをインストールする必要がある場合があります。問題が発生した場合は、拡張機能のドキュメントを参照してください。

devcontainer.json への拡張機能の追加

devcontainer.json ファイルを手動で編集して拡張機能 ID のリストを追加することもできますが、「拡張機能」ビューで任意の拡張機能を右クリックし、Add to devcontainer.json (devcontainer.json に追加) を選択することもできます。

Add to devcontainer.json menu

拡張機能のオプトアウト (除外)

ベースイメージまたは Feature が、開発コンテナーにインストールしたくない拡張機能を構成している場合は、マイナス記号を付けて拡張機能をリストすることでオプトアウトできます。例えば、次のようになります

{
  "image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bookworm",
  "customizations": {
    "vscode": {
      "extensions": ["-dbaeumer.vscode-eslint"]
    }
  }
}

「常にインストールされる」拡張機能

任意のコンテナーに常にインストールしておきたい拡張機能がある場合は、 dev.containers.defaultExtensions VS Code で開く VS Code Insiders で開くユーザー設定を更新できます。例えば、GitLens と Resource Monitor 拡張機能をインストールしたい場合は、次のように拡張機能 ID を指定します

"dev.containers.defaultExtensions": [
    "eamodio.gitlens",
    "mutantdino.resourcemonitor"
]

高度な設定: 拡張機能をローカルまたはリモートで強制的に実行する

拡張機能は通常、ローカルまたはリモートのいずれかで実行するように設計・テストされており、両方ではありません。ただし、拡張機能がサポートしている場合は、settings.json ファイルで特定の場所に実行するように強制できます。

たとえば、次の設定は、Container Tools 拡張機能をローカルで実行するように、および Remote - SSH: Editing Configuration Files 拡張機能をデフォルトとは逆にリモートで実行するように強制します。

"remote.extensionKind": {
    "ms-azuretools.vscode-containers": [ "ui" ],
    "ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}

"workspace" の代わりに "ui" の値を指定すると、代わりにローカルの UI/クライアント側で拡張機能を強制的に実行します。通常、これは拡張機能を破損させる可能性があるため、拡張機能のドキュメントに記載がない限り、テスト目的以外では使用しないでください。詳細は、推奨される拡張機能の場所に関するセクションを参照してください。

ポートの転送または公開

コンテナーは独立した環境であるため、コンテナー内のサーバー、サービス、またはその他のリソースにアクセスしたい場合は、ホストに対してポートを「転送」または「公開」する必要があります。これらのポートを常に公開するようにコンテナーを構成するか、一時的に転送するかを選択できます。

ポートを常に転送する

コンテナーにアタッチしたり、コンテナーでフォルダーを開いたりする際に常に転送したいポートのリストを、devcontainer.json の forwardPorts プロパティを使用して指定できます。

"forwardPorts": [3000, 3001]

ウィンドウをリロードまたは再度開くだけで、VS Code がコンテナーに接続したときに設定が適用されます。

ポートを一時的に転送する

devcontainer.json に追加しなかった、または Docker Compose ファイルで公開しなかったポートにアクセスする必要がある場合は、コマンドパレット (F1) から Forward a Port (ポートを転送) コマンドを実行することで、セッションの間だけ新しいポートを一時的に転送できます。

Forward port input

ポートを選択すると、コンテナー内のポートにアクセスするために使用すべき localhost ポートが通知されます。例えば、ポート 3000 でリッスンしている HTTP サーバーを転送した場合、通知には localhost のポート 4123 にマッピングされたことが示されるかもしれません。その場合、https://:4123 を使用してこのリモート HTTP サーバーに接続できます。

後でアクセスする必要がある場合、この同じ情報はリモートエクスプローラーの Forwarded Ports (転送されたポート) セクションでも確認できます。

VS Code に転送したポートを記憶させたい場合は、設定エディター (⌘, (Windows, Linux は Ctrl+,)) で Remote: Restore Forwarded Ports にチェックを入れるか、settings.json で "remote.restoreForwardedPorts": true を設定してください。

Restore forwarded ports setting

ポートの公開

Docker には、コンテナー作成時にポートを「公開 (publish)」するという概念があります。公開されたポートは、ローカルネットワークで利用可能にするポートと非常によく似た動作をします。アプリケーションが localhost からの呼び出しのみを受け入れる場合、ネットワーク呼び出しに対してローカルマシンが行うのと同様に、公開されたポートからの接続を拒否します。一方、転送されたポートは、アプリケーションからは localhost のように見えます。それぞれが異なる状況で役立ちます。

ポートを公開するには、以下の方法があります

appPort プロパティを使用する: devcontainer.json でイメージまたは Dockerfile を参照している場合は、appPort プロパティを使用してホストにポートを公開できます。
```
"appPort": [ 3000, "8921:5000" ]
```
Docker Compose のポートマッピングを使用する: docker-compose.yml ファイルに ports マッピングを簡単に追加して、追加のポートを公開できます。
```
ports:
- "3000"
- "8921:5000"
```

いずれの場合も、設定を有効にするにはコンテナーを再ビルドする必要があります。コンテナーに接続しているときに、コマンドパレット (F1) で Dev Containers: Rebuild Container (コンテナーの再ビルド) コマンドを実行することでこれを行うことができます。

ターミナルを開く

VS Code からコンテナー内のターミナルを開くのは簡単です。コンテナーでフォルダーを開くと、VS Code で開くすべてのターミナルウィンドウ (Terminal > New Terminal) は、ローカルではなく自動的にコンテナー内で実行されます。

また、この同じターミナルウィンドウから code コマンドラインを使用して、コンテナー内で新しいファイルやフォルダーを開くなどの様々な操作を実行できます。コマンドラインで使用可能なオプションについては、code --help と入力して確認してください。

Using the code CLI

コンテナーでのデバッグ

コンテナーでフォルダーを開くと、アプリケーションをローカルで実行しているときと同じように VS Code のデバッガーを使用できます。例えば、launch.json で起動構成を選択してデバッグを開始 (F5) すると、アプリケーションがリモートホスト上で起動し、デバッガーがそれにアタッチされます。

.vscode/launch.json で VS Code のデバッグ機能を構成する方法の詳細については、デバッグドキュメントを参照してください。

コンテナー固有の設定

VS Code のローカルユーザー設定は、開発コンテナーに接続しているときも再利用されます。これによりユーザーエクスペリエンスの一貫性が保たれますが、ローカルマシンと各コンテナーの間でこれらの一部を変えたい場合があります。幸いなことに、コンテナーに接続したら、コマンドパレット (F1) から Preferences: Open Remote Settings (基本設定: リモート設定を開く) コマンドを実行するか、設定エディターで Remote タブを選択することで、コンテナー固有の設定を行うこともできます。これらは、コンテナーに接続している間、既存のローカル設定よりも優先されます。

Container specific settings tab

デフォルトのコンテナー固有の設定

devcontainer.json の settings プロパティを使用して、コンテナー固有の設定のデフォルトを含めることができます。これらの値は、コンテナーが作成されると、コンテナー内のコンテナー固有設定ファイルに自動的に配置されます。

例えば、.devcontainer/devcontainer.json にこれを追加すると、Java ホームパスが設定されます

// Configure tool-specific properties.
"customizations": {
    // Configure properties specific to VS Code.
    "vscode": {
        "settings": {
            "java.home": "/docker-java-home"
        }
    }
}

これは単にデフォルトを確立するものであるため、コンテナーが作成された後、必要に応じて設定を変更することができます。

コンテナーの管理

デフォルトでは、フォルダーを開いたときに、Dev Containers 拡張機能は devcontainer.json に記載されているコンテナーを自動的に起動します。VS Code を閉じると、拡張機能は接続していたコンテナーを自動的にシャットダウンします。この動作を変更するには、devcontainer.json に "shutdownAction": "none" を追加します。

コマンドラインを使用してコンテナーを管理することもできますが、リモートエクスプローラー を使用することもできます。コンテナーを停止するには、ドロップダウンから「コンテナー」を選択し（存在する場合）、実行中のコンテナーを右クリックして Stop Container (コンテナーの停止) を選択します。また、終了したコンテナーの起動、コンテナーの削除、最近使用したフォルダーの削除も行えます。「詳細」ビューからは、ポートの転送や、すでに転送されているポートをブラウザーで開くことができます。

Containers Explorer screenshot

イメージを整理したりコンテナーを一括削除したりしたい場合は、様々なオプションについて未使用のコンテナーとイメージの整理を参照してください。

dotfile リポジトリによるパーソナライズ

Dotfile は、ファイル名がドット (.) で始まるファイルで、通常、様々なアプリケーションの構成情報が含まれています。開発コンテナーは幅広い種類のアプリケーションをカバーできるため、これらのファイルをどこかに保存しておき、コンテナーが起動した後に簡単にコピーできるようにしておくと便利です。

これを行う一般的な方法は、これらの dotfile を GitHub リポジトリに保存し、ユーティリティを使用してそれらをクローンして適用することです。Dev Containers 拡張機能には、独自のコンテナーでこれらを使用するための組み込みサポートがあります。このアイデアが初めての方は、存在する様々な dotfile ブートストラップリポジトリを見てみてください。

これを使用するには、以下のように dotfile の GitHub リポジトリを VS Code のユーザー設定 (⌘, (Windows, Linux は Ctrl+,)) に追加します

Settings for dotfiles

または settings.json 内で

{
  "dotfiles.repository": "your-github-id/your-dotfiles-repo",
  "dotfiles.targetPath": "~/dotfiles",
  "dotfiles.installCommand": "install.sh"
}

これ以降、コンテナーが作成されるたびに dotfile リポジトリが使用されます。

既知の制限事項

開発コンテナーの制限事項

Windows コンテナーイメージはサポートされていません。
マルチルートワークスペース内のすべてのルート/フォルダーは、下位レベルに構成ファイルがあるかどうかに関わらず、同じコンテナーで開かれます。
非公式の Ubuntu Docker snap パッケージ (Linux 用) はサポートされていません。お使いのディストリビューション用の公式 Docker インストール手順に従ってください。
Windows 上の Docker Toolbox はサポートされていません。
SSH を使用して Git リポジトリをクローンし、SSH キーにパスフレーズがある場合、リモートで実行すると VS Code のプルおよび同期機能がハングする可能性があります。パスフレーズのない SSH キーを使用するか、HTTPS を使用してクローンするか、コマンドラインから git push を実行して問題を回避してください。
ローカルのプロキシ設定はコンテナー内では再利用されません。適切なプロキシ情報（例えば、適切なプロキシ情報を含むグローバルな HTTP_PROXY または HTTPS_PROXY 環境変数）が構成されていない限り、拡張機能が動作しない可能性があります。
Windows 上の OpenSSH バージョンにおいて、ssh-agent がバージョン 8.8 以下で実行され、SSH クライアント（任意のプラットフォーム）がバージョン 8.9 以上で実行されている場合に互換性がない問題があります。回避策は、winget または Win32-OpenSSH/releases のインストーラーを使用して、Windows 上の OpenSSH を 8.9 以降にアップグレードすることです。（注：ssh-add -l は正しく動作しますが、ssh <ssh-server> は <ssh-server>: Permission denied (publickey) で失敗します。これはリポジトリへの接続に SSH を使用する場合の Git にも影響します。）

コンテナーに関連するアクティブな問題のリストについては、こちらを参照してください。

Docker の制限事項

詳細については、Windows または Mac 用の Docker トラブルシューティングガイドを参照してください。

Container Tools 拡張機能の制限事項

WSL、Remote - Tunnels、または Remote - SSH ウィンドウから Container Tools または Kubernetes 拡張機能を使用している場合、Container Explorer または Kubernetes ビューで Attach Visual Studio Code コンテキストメニューアクションを使用すると、利用可能なコンテナーから再度選択するように求められます。

拡張機能の制限事項

現時点では、ほとんどの拡張機能が修正なしで開発コンテナー内で動作します。ただし、場合によっては特定の機能に変更が必要になることがあります。拡張機能の問題に遭遇した場合は、問題を作者に報告する際に言及できる、一般的な問題と解決策の概要をこちらで確認してください。

また、Alpine のサポートは利用可能ですが、コンテナーにインストールされた一部の拡張機能は、拡張機能内のネイティブコードにおける glibc 依存関係のために動作しない場合があります。詳細は Linux でのリモート開発の記事を参照してください。

高度なコンテナ構成

以下のトピックに関する情報は、高度なコンテナー構成の記事を参照してください

devcontainer.json リファレンス

完全な devcontainer.json リファレンスがあり、ファイルスキーマを確認して、開発コンテナーのカスタマイズや実行中のコンテナーへのアタッチ方法の制御に役立てることができます。

質問またはフィードバック

ヒントとコツまたは FAQ を参照してください。
Stack Overflow で検索してください。
機能リクエストを追加するか、問題を報告してください。
他の人が使用できる開発コンテナテンプレートまたは機能を作成します。
Development Containers Specification を確認し、フィードバックを提供してください。
ドキュメントまたはVS Code 自体に貢献してください。
詳細については、CONTRIBUTING ガイドを参照してください。

トラブルシューティング

ファイルを書き込めません (NoPermissions (FileSystemError))

以下の構成で開発コンテナーを実行している場合、この問題に遭遇する可能性があります

WSL バックエンドで動作している Docker Desktop
Enhanced Container Isolation (ECI) が有効

潜在的な回避策については、問題 #8278 を確認してください。

次のステップ

実行中のコンテナーにアタッチ - すでに実行されている Docker コンテナーにアタッチします。
開発コンテナーの作成 - 作業環境に合わせてカスタムコンテナーを作成します。
高度なコンテナ - 高度なコンテナシナリオのソリューションを見つけます。
devcontainer.jsonリファレンス - devcontainer.jsonスキーマを確認します。

5/28/2026