コンテナー内で開発する

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をサポートしており、これによりあらゆるツールの誰もが整合性のある開発環境を構成できます。詳細は開発コンテナーのFAQと、仕様サイトcontainers.devで確認できます。

はじめに

注: 開発コンテナーをすばやく使い始める方法は、導入のDev Containersチュートリアルで学ぶことができます。

システム要件

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

DockerをDev Containers拡張機能で使用するには、いくつかの方法があります。

ローカルに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フォルダーを参照して、各テンプレートの内容を確認できます。

また、開発コンテナー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ファイルを含むフォルダーを開いたら、ファイル > ワークスペースを開く...を使用します。

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

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

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

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

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

例えば、リポジトリコンテナーで「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拡張機能はワークスペース信頼を採用しています。ソースコードの開き方や操作方法に応じて、異なる時点で編集または実行しているコードを信頼するかどうかを決定するように求められます。

コンテナーでフォルダーを再オープンする

既存のプロジェクトに開発コンテナーを設定するには、ローカル (または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ファイルの作成について詳しく知るには、開発コンテナーの作成を参照してください。

Dev Container Features

開発コンテナーの「Features」は、自己完結型で共有可能なインストールコードと開発コンテナー設定の単位です。この名前は、それらの1つを参照することで、あなたや共同作業者が使用するために、より多くのツール、ランタイム、またはライブラリの「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は、現在、中央インデックスから取得されており、あなたもこれに貢献できます。現在のリストと、Featuresの公開と配布方法については、Dev Containers仕様サイトを参照してください。

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

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

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

独自のFeatureを作成する

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

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

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

開発コンテナーCLIを使用して独自の公開またはプライベートFeaturesを公開する方法については、feature/starterリポジトリを確認してください。

Featuresの仕様と配布

Featuresは、オープンソースのDevelopment Containers Specificationの重要な部分です。Featuresの動作に関する詳細情報と、その配布方法を確認できます。

開発コンテナーイメージを事前にビルドする

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

さらに、事前にビルドされたイメージにはDev Containerメタデータを含めることができるため、イメージを参照すると設定が自動的に取得されます。

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

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

詳細については、イメージの事前ビルドに関する開発コンテナーCLIの記事を参照してください。

メタデータの継承

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

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

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

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

代わりに、イメージラベルにメタデータを手動で追加することも選択できます。これらのプロパティは、Dev Container 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を使用してこれらのコンテンツを操作できます。

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

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

Workspace Extension Category

Local Extension Category

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

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

Disabled Extensions w/Install Button

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

Install all extensions

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

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

devcontainer.jsonファイルを直接編集して拡張機能IDのリストを追加することもできますが、拡張機能ビューで任意の拡張機能を右クリックして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 port input

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

この同じ情報は、後でアクセスする必要がある場合、Remote Explorerの転送済みポートセクションで利用可能です。

転送したポートをVS Codeに記憶させたい場合は、設定エディター (⌘, (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のデバッグ機能の設定に関する詳細については、デバッグのドキュメントを参照してください。

コンテナー固有の設定

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

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"を追加することで変更できます。

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

Containers Explorer screenshot

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

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

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

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

これを使用するには、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上でssh-agentがバージョン8.8以下で実行され、SSHクライアント (任意のプラットフォーム) がバージョン8.9以上で実行されている場合、OpenSSHのバージョン間に非互換性があります。この問題の回避策は、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トラブルシューティングガイドを参照するか、詳細についてDockerサポートリソースを参照してください。

Container Tools拡張機能の制限事項

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

拡張機能の制限事項

現時点では、ほとんどの拡張機能は変更なしでDev Containers内で動作します。ただし、場合によっては、特定の機能が変更を必要とすることがあります。拡張機能の問題に遭遇した場合は、一般的な問題と解決策の概要をこちらで確認し、問題を報告する際に拡張機能の作成者に伝えることができます。

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

高度なコンテナー構成

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

devcontainer.json リファレンス

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

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

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

トラブルシューティング

ファイルを書き込めません (アクセス許可がありません (FileSystemError))

次の構成で開発コンテナーを実行すると、この問題に遭遇する可能性があります。

Windows Subsystem for Linux (WSL) バックエンドで実行中のDocker Desktop
強化されたコンテナー分離 (ECI) が有効

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

次のステップ

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

07/09/2025