編集

コンテナー内での開発

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

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

Container Architecture

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

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

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

注: Dev Containers 拡張機能は、オープンな Dev Containers Specification をサポートしており、これにより、任意のツールで誰でも一貫した開発環境を構成できます。詳細については、dev container FAQと仕様サイトcontainers.devをご覧ください。

はじめに

注: dev container の導入チュートリアルで、dev container をすぐに使い始める方法を学ぶことができます。

システム要件

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

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 スナップパッケージはサポートされていません。)
リモートホスト: 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+

必要な Linux 前提条件がある場合、他のglibcベースの 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がインストールされている場合は、dev containerで開くを使用できます。これと、リポジトリに追加する方法の詳細については、dev containerの作成ガイドを参照してください。

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

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

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

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

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

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

追加の機能で開発コンテナーをカスタマイズできる場合があります。詳細はこちらをご覧ください。

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

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

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

ヒント: リモート 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 ファイルを含むフォルダーを開いた後、ファイル > ワークスペースを開く... を使用します。

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

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

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

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

リポジトリコンテナは、ローカルファイルシステムにバインドする代わりに、分離されたローカルDockerボリュームを使用します。ファイルツリーを汚染しないことに加えて、ローカルボリュームにはWindowsおよびmacOSでのパフォーマンス向上という利点があります。(他のシナリオでこれらの種類のボリュームを使用する方法については、Advanced Configurationのディスクパフォーマンスの向上の記事を参照してください。)

例えば、「try」リポジトリのいずれかをリポジトリコンテナで開くには、次の手順に従います。

VS Code を起動し、コマンドパレット (F1) から Dev Containers: Clone Repository in Container Volume... を実行します。
表示された入力ボックスに microsoft/vscode-remote-try-node (または他の「try」リポジトリのいずれか)、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 拡張機能はワークスペースの信頼を採用しています。ソースコードを開いたり操作したりする方法に応じて、編集または実行しているコードを信頼するかどうかをさまざまな時点で決定するよう求められます。

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

既存のプロジェクトの dev コンテナーのセットアップには、ローカル (または 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 ファイルに似ていますが、開発コンテナーの起動 (またはアタッチ) に使用されます。コンテナーの実行後にインストールする拡張機能や、環境を準備するための作成後コマンドも指定できます。dev コンテナー構成は、.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ファイルの作成の詳細については、開発コンテナーの作成を参照してください。

Dev Container の機能

開発コンテナーの「機能 (Features)」は、自己完結型で共有可能なインストールコードと dev コンテナー構成の単位です。この名前は、それらのいずれかを参照することで、開発コンテナーにツール、ランタイム、またはライブラリの「機能」をすばやく簡単に追加して、自分や共同作業者が使用できるようにするという考えから来ています。

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

Dev container Features list drop down

コンテナーでリビルドして再開すると、選択した機能が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 で提供される機能は、中央インデックスから取得され、貢献することもできます。現在のリストについてはDev Containers 仕様サイトを参照し、機能の公開と配布方法を学ぶこともできます。

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

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

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

独自の機能を作成する

独自の Dev Container Feature を作成して公開することも簡単です。公開された Feature は、対応するパブリックまたはプライベートコンテナレジストリからOCI Artifactとして保存および共有できます。現在公開されている Feature のリストはcontainers.devで確認できます。

機能とは、少なくともdevcontainer-feature.jsonとinstall.shエントリポイントスクリプトを持つフォルダ内の自己完結型エンティティです。

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

独自のパブリックまたはプライベート機能を公開するために dev container CLI を使用する方法については、feature/starter リポジトリを参照してください。

機能の仕様と配布

機能は、オープンソースの開発コンテナー仕様の重要な部分です。機能の仕組みと配布に関する詳細情報をご覧ください。

開発コンテナーイメージの事前構築

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

さらに良いことに、事前構築されたイメージには Dev Container メタデータを含めることができるため、イメージを参照すると設定が自動的に引き継がれます。

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

devcontainers/ci リポジトリの GitHub Action を使用して、ワークフローで開発コンテナーを再利用することができます。

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

メタデータの継承

イメージラベルを介して、事前構築済みイメージに Dev Container 構成および機能のメタデータを含めることができます。これにより、イメージは自己完結型となり、直接、参照されている Dockerfile の FROM 内、または Docker Compose ファイル内でイメージが参照されると、これらの設定が自動的に取得されます。これにより、Dev Container 構成とイメージの内容の同期がずれるのを防ぎ、シンプルなイメージ参照を介して同じ構成の更新を複数のリポジトリにプッシュできるようになります。

このメタデータラベルは、Dev Container CLI (または仕様をサポートするGitHub ActionやAzure DevOps タスクなどのユーティリティ) を使用して事前構築する際に自動的に追加され、devcontainer.jsonからの設定と参照されているDev Container 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の名前付きボリュームを使用しており、それを検査したり変更したりしたい状況に遭遇することがあります。コマンドパレット(F1)からDev Containers: Explore a Volume in a Dev Container...を選択することで、devcontainer.jsonファイルを作成したり変更したりすることなく、VS Codeを使用してこれらの内容を操作できます。

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

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

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

Workspace Extension Category

Local Extension Category

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

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

Disabled Extensions w/Install Button

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

Install all extensions

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

devcontainer.json に拡張機能を追加する

拡張機能 ID のリストを手動でdevcontainer.jsonファイルに追加することもできますが、拡張機能ビューの任意の拡張機能を右クリックしてAdd to 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ユーザー設定を更新できます。たとえば、GitLensおよびResource Monitor拡張機能をインストールしたい場合、その拡張機能IDを次のように指定します。

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

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

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

たとえば、以下の設定は、Container Tools拡張機能をローカルで強制的に実行し、Remote - SSH: 設定ファイルの編集拡張機能をデフォルトとは異なりリモートで強制的に実行します。

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

Restore forwarded ports setting

ポートの公開

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

ポートを公開するには、次のいずれかを実行できます。

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

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

ターミナルを開く

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

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

Using the code CLI

コンテナー内でのデバッグ

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

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

コンテナー固有の設定

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

Container specific settings tab

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

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

例えば、これを.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" を追加することで変更できます。

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

Containers Explorer screenshot

イメージのクリーンアップやコンテナーの一括削除については、未使用のコンテナーとイメージのクリーンアップを参照して、さまざまなオプションを確認してください。

ドットファイルリポジトリによるパーソナライズ

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

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

使用するには、次のように、VS Code のユーザー設定 (⌘, (Windows, Linux Ctrl+,)) にドットファイル GitHub リポジトリを追加します。

Settings for dotfiles

または settings.json で

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

この時点から、コンテナーが作成されるたびにドットファイルリポジトリが使用されます。

既知の制限事項

Dev Containers の制限事項

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

コンテナーに関するアクティブな問題のリストはこちらをご覧ください。

Docker の制限事項

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

Container Tools拡張機能の制限事項

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

拡張機能の制限事項

この時点では、ほとんどの拡張機能は変更なしに Dev Containers 内で動作します。ただし、場合によっては、特定の機能が変更を必要とする場合があります。拡張機能の問題が発生した場合は、こちらに一般的な問題と解決策の概要がありますので、問題報告時に拡張機能の作成者に言及してください。

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

高度なコンテナー構成

Advanced container configuration の記事では、以下のトピックに関する情報を提供しています。

devcontainer.json リファレンス

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

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

ヒントとテクニックまたはFAQをご覧ください。
Stack Overflowで検索します。
機能リクエストを追加するか、問題を報告します。
他の人が使用できるようにDev Container TemplateまたはFeatureを作成します。
Development Containers Specificationについてレビューし、フィードバックを提供してください。
弊社のドキュメントまたはVS Code自体に貢献します。
詳細については、CONTRIBUTINGガイドを参照してください。

トラブルシューティング

ファイルへの書き込みができません (NoPermissions (FileSystemError))

以下の構成で開発コンテナを実行すると、この問題が発生する可能性があります。

Windows Subsystem for Linux (WSL) バックエンドで動作する Docker Desktop
強化されたコンテナー分離 (ECI) が有効になっています。

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

次のステップ

実行中のコンテナーにアタッチする - 既に実行中の Docker コンテナーにアタッチします。
開発コンテナーを作成する - 作業環境用のカスタムコンテナーを作成します。
高度なコンテナー - 高度なコンテナーシナリオの解決策を見つけます。
devcontainer.jsonリファレンス - devcontainer.jsonスキーマを確認します。

08/07/2025