コンテナー内での開発
Visual Studio Code Dev Containers 拡張機能を使用すると、コンテナーをフル機能の開発環境として使用できます。これにより、コンテナー内部 (またはマウントされた) の任意のフォルダーを開き、Visual Studio Code のすべての機能を活用できます。プロジェクト内の devcontainer.json ファイル は、VS Code に、適切に定義されたツールとランタイム スタックを備えた開発コンテナーにアクセス (または作成) する方法を指示します。このコンテナーは、アプリケーションを実行したり、コードベースの操作に必要なツール、ライブラリ、またはランタイムを分離するために使用できます。
ワークスペース ファイルは、ローカル ファイル システムからマウントされるか、コンテナーにコピーまたはクローンされます。拡張機能はコンテナー内にインストールされて実行され、ツール、プラットフォーム、およびファイル システムへのフル アクセス権を持ちます。つまり、別のコンテナーに接続するだけで、開発環境全体をシームレスに切り替えることができます。
これにより、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 オプション (リモート ホスト上の Docker や Docker 準拠の CLI など) を使用します。
Windows / macOS:
-
Docker Desktop for Windows/Mac をインストールします。
-
Windows で WSL 2 を使用している場合は、WSL 2 バックエンド が有効になっていることを確認するために、Docker タスクバー アイテムを右クリックして [設定] を選択します。[WSL 2 ベースのエンジンを使用する] をオンにし、[リソース] > [WSL 統合] でディストリビューションが有効になっていることを確認します。
-
WSL 2 バックエンドを使用していない場合は、Docker タスクバー アイテムを右クリックし、[設定] を選択して、ソース コードが保存されている場所で [リソース] > [ファイル共有] を更新します。トラブルシューティングについては、ヒントとテクニック を参照してください。
Linux:
-
ディストリビューション用の Docker CE/EE の公式インストール手順に従ってください。Docker Compose を使用している場合は、Docker Compose の手順にも従ってください。
-
ターミナルを使用して
sudo usermod -aG docker $USERを実行して、ユーザーをdockerグループに追加します。 -
変更を有効にするために、サインアウトして再度サインインします。
-
-
Visual Studio Code または Visual Studio Code Insiders をインストールします。
-
Dev Containers 拡張機能をインストールします。VS Code で他のリモート拡張機能を使用する予定がある場合は、Remote Development 拡張機能パックをインストールすることもできます。
Git を使用していますか?
考慮すべき 2 つのヒントを次に示します。
- Windows のローカルとコンテナー内部の両方で同じリポジトリを操作している場合は、必ず一貫した改行コードを設定してください。詳細については、ヒントとテクニックを参照してください。
- Git 認証情報マネージャーを使用してクローンを作成する場合、コンテナーは既に認証情報にアクセスできるはずです。SSH キーを使用する場合は、共有することもできます。詳細については、コンテナーとの Git 認証情報の共有を参照してください。
クイック スタートの選択
このドキュメントには 3 つのクイック スタートが含まれています。ワークフローと関心に最も適したものを開始することをお勧めします。
- クイック サンプル リポジトリで開発コンテナーを試してみませんか? クイック スタート 1: 開発コンテナーを試す を確認してください。
- 既存のローカルにクローンされたプロジェクトの 1 つに開発コンテナーを追加しますか? クイック スタート 2: コンテナー内で既存のフォルダーを開く を確認してください。
- ローカル作業に影響を与えずに、PR をレビューしたり、ブランチを調査したりするために、リポジトリの分離されたコピーを操作しますか? クイック スタート 3: 分離されたコンテナー ボリュームで Git リポジトリまたは GitHub PR を開く を確認してください。
クイック スタート: 開発コンテナーを試す
開始する最も簡単な方法は、サンプル開発コンテナーの 1 つを試すことです。コンテナー チュートリアルでは、Docker と Dev Containers 拡張機能をセットアップし、サンプルを選択する手順を説明します。
注: VS Code と Docker が既にインストールされている場合は、開発コンテナーで開く を使用できます。これの詳細と、リポジトリに追加する方法については、開発コンテナーの作成ガイドを参照してください。
クイック スタート: コンテナー内で既存のフォルダーを開く
このクイック スタートでは、ファイルシステム上の既存のソース コードを使用して、フルタイムの開発環境として使用する既存のプロジェクトの開発コンテナーをセットアップする方法について説明します。次の手順に従ってください。
-
VS Code を起動し、コマンド パレット (F1) またはクイック アクション ステータス バー アイテムから [Dev Containers: コンテナーでフォルダーを開く...] コマンドを実行し、コンテナーをセットアップするプロジェクト フォルダーを選択します。
ヒント: フォルダーを開く前にコンテナーの内容または設定を編集する場合は、代わりに [Dev Containers: 開発コンテナー構成ファイルを追加...] を実行できます。
-
次に、開発コンテナーの開始点を選択します。フィルター可能なリストから基本の 開発コンテナー テンプレート を選択するか、選択したフォルダーに既存の Dockerfile または Docker Compose ファイル が存在する場合はそれらを使用できます。
注: Alpine Linux コンテナーを使用する場合、一部の拡張機能は、拡張機能内のネイティブ コードの
glibc依存関係が原因で動作しない場合があります。
リストは、開くフォルダーの内容に基づいて自動的にソートされます。
追加の機能で開発コンテナーをカスタマイズできる場合があります。詳細については、以下をお読みください。
表示される開発コンテナー テンプレートは、ファースト パーティおよびコミュニティ インデックスからのものであり、Dev Container 仕様の一部です。仕様の一部として、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: コンテナーで再度開く] コマンドを使用します。
- コマンド パレット (F1) から [Dev Containers: コンテナーでフォルダーを開く...] を選択し、ローカルの
\\wsl$共有 (Windows 側から) を使用して WSL フォルダーを選択します。
クイック スタートの残りの部分はそのまま適用されます。WSL 拡張機能の詳細については、ドキュメントを参照してください。
リモート SSH ホスト上のフォルダーをコンテナーで開く
Linux または macOS SSH ホストを使用している場合は、Remote - SSH 拡張機能と Dev Containers 拡張機能を組み合わせて使用できます。Docker クライアントをローカルにインストールする必要さえありません。
そのためには、
- Remote - SSH 拡張機能の インストール および SSH ホスト セットアップ 手順に従います。
- オプション: パスワードを複数回入力する必要がないように、SSH キーベース認証 をサーバーにセットアップします。
- Docker をインストールします。ローカルに Docker をインストールする必要はありません。
- Remote - SSH 拡張機能の クイック スタート に従って、ホストに接続してフォルダーを開きます。
- コマンド パレット (F1、⇧⌘P (Windows、Linux Ctrl+Shift+P)) から [Dev Containers: コンテナーで再度開く] コマンドを使用します。
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: コンテナーで再度開く] コマンドを使用します。
Dev Containers クイック スタートの残りの部分はそのまま適用されます。Remote - Tunnels 拡張機能の詳細については、ドキュメントを参照してください。このモデルがニーズに合わない場合は、リモート Docker ホストでの開発に関する記事も参照してください。
コンテナーで既存のワークスペースを開く
ワークスペースが .code-workspace ファイルがあるフォルダー (またはフォルダー自体) のサブフォルダーへの相対パスのみを参照している 場合、同様のプロセスに従って、単一のコンテナー で VS Code マルチルート ワークスペース を開くこともできます。
次のいずれかを実行できます。
- [Dev Containers: コンテナーでワークスペースを開く...] コマンドを使用します。
- コンテナーで
.code-workspaceファイルを含むフォルダーを開いたら、[ファイル] > [ワークスペースを開く...] を使用します。
接続したら、.devcontainer フォルダー をワークスペースに追加して、まだ表示されていない場合にその内容を簡単に編集できるようにすることをお勧めします。
また、同じ VS Code ウィンドウで同じワークスペースに複数のコンテナーを使用することはできませんが、別のウィンドウから 複数の Docker Compose 管理コンテナーを同時に 使用できます。
クイック スタート: 分離されたコンテナー ボリュームで Git リポジトリまたは GitHub PR を開く
ローカルにクローンされたリポジトリをコンテナーで開く ことはできますが、PR レビューや別のブランチを調査するために、ローカル作業に影響を与えずにリポジトリの分離されたコピーを操作したい場合があります。
リポジトリ コンテナーは、ローカル ファイルシステムにバインドする代わりに、分離されたローカル Docker ボリュームを使用します。ローカル ボリュームは、ファイル ツリーを汚染しないだけでなく、Windows および macOS でのパフォーマンスが向上するという利点もあります。(これらのタイプのボリュームを他のシナリオで使用する方法については、高度な構成 ディスク パフォーマンスの向上 に関する記事を参照してください。)
たとえば、次の手順に従って、「try」リポジトリの 1 つをリポジトリ コンテナーで開きます。
-
VS Code を起動し、コマンド パレット (F1) から [Dev Containers: コンテナー ボリュームにリポジトリをクローン...] を実行します。
-
表示される入力ボックスに
microsoft/vscode-remote-try-node(または他の「try」リポジトリの 1 つ)、Git URI、GitHub ブランチ URL、または GitHub PR URL を入力し、Enter を押します。
ヒント: プライベート リポジトリを選択する場合は、認証情報マネージャーをセットアップするか、SSH キーを SSH エージェントに追加することをお勧めします。コンテナーとの Git 認証情報の共有を参照してください。
-
リポジトリに
.devcontainer/devcontainer.jsonファイルがない場合は、フィルター可能なリストから開始点を選択するか、既存の Dockerfile または Docker Compose ファイル (存在する場合) を選択するように求められます。注: Alpine Linux コンテナーを使用する場合、一部の拡張機能は、拡張機能内のネイティブ コードの
glibc依存関係が原因で動作しない場合があります。リストは、開くフォルダーの内容に基づいて自動的にソートされます。表示される開発コンテナー テンプレートは、ファースト パーティおよびコミュニティ インデックスからのものであり、Dev Container 仕様の一部です。仕様の一部として、devcontainers/templates リポジトリにテンプレートのセットをホストしています。各テンプレートの内容を確認するには、そのリポジトリの
srcフォルダーを参照できます。 -
VS Code ウィンドウ (インスタンス) がリロードされ、ソース コードがクローンされ、開発コンテナーのビルドが開始されます。進行状況通知にステータス更新が表示されます。
手順 2 で GitHub プル リクエスト URL を貼り付けた場合、PR は自動的にチェックアウトされ、GitHub Pull Requests 拡張機能がコンテナーにインストールされます。この拡張機能は、PR エクスプローラー、PR コメントのインライン操作、ステータス バーの可視性など、PR 関連の追加機能を提供します。
-
ビルドが完了すると、VS Code は自動的にコンテナーに接続します。コードをローカルにクローンした場合と同じように、この独立した環境でリポジトリ ソース コードを操作できるようになりました。
Docker ビルド エラーなどの原因でコンテナーが起動に失敗した場合は、表示されるダイアログで [リカバリ コンテナーで再度開く] を選択して、「リカバリ コンテナー」に移動し、Dockerfile またはその他のコンテンツを編集できます。これにより、クローンされたリポジトリを含む Docker ボリュームが最小限のコンテナーで開き、作成ログが表示されます。修正が完了したら、[コンテナーで再度開く] を使用して再試行します。
ヒント: リモート Docker ホストを使用しますか? 詳細については、リモート SSH ホスト上のフォルダーをコンテナーで開くセクションを参照してください。
ワークスペースを信頼する
Visual Studio Code はセキュリティを重視しており、ソースや元の作成者が誰であれ、コードを安全に参照および編集できるように支援したいと考えています。ワークスペースの信頼機能を使用すると、プロジェクト フォルダーで自動コード実行を許可するか制限するかを決定できます。
Dev Containers 拡張機能は、ワークスペースの信頼を採用しています。ソース コードを開いて操作する方法に応じて、編集または実行しているコードを信頼するかどうかをさまざまな時点で決定するように求められます。
コンテナーでフォルダーを再度開く
既存のプロジェクトの開発コンテナーをセットアップするには、ローカル (または WSL) フォルダーを信頼する必要があります。ウィンドウがリロードされる前に、ローカル (または WSL) フォルダーを信頼するように求められます。
このフローにはいくつかの例外があります。
- 最近使用したエントリをクリックした場合。
- [コンテナーでフォルダーを開く] コマンドを使用すると、信頼がまだ付与されていない場合は、ウィンドウのリロード後に信頼を求められます。
既存のコンテナーにアタッチ
既存のコンテナーにアタッチする場合、アタッチするとコンテナーを信頼することを意味することを確認するように求められます。これは一度だけ確認されます。
ボリュームにリポジトリをクローン
コンテナー ボリュームにリポジトリをクローンする場合、リポジトリをクローンするとリポジトリを信頼することを意味することを確認するように求められます。これは一度だけ確認されます。
ボリュームの検査
ボリュームの検査 は 制限付きモード で開始され、コンテナー内のフォルダーを信頼できます。
リモートで実行されている Docker デーモン
これは、Docker デーモンが実行されているマシンを信頼することを意味します。確認を求める追加のプロンプトはありません (上記のローカル/WSL ケースにリストされているプロンプトのみ)。
devcontainer.json ファイルを作成する
VS Code のコンテナー構成は、devcontainer.json ファイルに保存されます。このファイルは、デバッグ構成の launch.json ファイルに似ていますが、代わりに開発コンテナーを起動 (またはアタッチ) するために使用されます。コンテナーの実行後にインストールする拡張機能や、環境を準備するための作成後コマンドも指定できます。開発コンテナー構成は、.devcontainer/devcontainer.json にあるか、プロジェクトのルートに .devcontainer.json ファイル (ドットプレフィックスに注意) として保存されます。
コマンド パレット (F1) から [Dev Containers: 開発コンテナー構成ファイルを追加...] コマンドを選択すると、開始点として必要なファイルがプロジェクトに追加されます。これらは、ニーズに合わせてさらにカスタマイズできます。このコマンドを使用すると、フォルダーの内容に基づいてリストから事前定義されたコンテナー構成を選択したり、既存の Dockerfile を再利用したり、既存の Docker Compose ファイルを再利用したりできます。
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 ファイルの作成の詳細については、開発コンテナーの作成を参照してください。
開発コンテナーの機能
開発コンテナー「機能」は、自己完結型で共有可能なインストール コードと開発コンテナー構成のユニットです。名前の由来は、その 1 つを参照することで、ツール、ランタイム、またはライブラリの「機能」を開発コンテナーに迅速かつ簡単に追加して、自分や共同作業者が使用できるようにするという考え方に基づいています。
[Dev Containers: 開発コンテナー構成ファイルを追加] を使用すると、Git や Azure CLI のインストールなど、既存の開発コンテナー構成をカスタマイズするためのスクリプトのリストが表示されます。
コンテナーでリビルドして再度開くと、選択した機能が devcontainer.json で使用可能になります。
"features": {
"ghcr.io/devcontainers/features/github-cli:1": {
"version": "latest"
}
}
devcontainer.json で "features" プロパティを直接編集すると、IntelliSense が表示されます。
[Dev Containers: コンテナー機能の構成] コマンドを使用すると、既存の構成を更新できます。
VS Code UI でソース コード化された機能は、現在中央インデックスから取得されており、これに貢献することもできます。現在のリストと 機能の公開と配布の方法については、Dev Containers 仕様サイトを参照してください。
「常にインストールされる」機能
開発コンテナーで 常にインストールされるように拡張機能を設定する のと同様に、dev.containers.defaultFeatures ユーザー 設定 を使用して、常にインストールしたい機能を設定できます。
"dev.containers.defaultFeatures": {
"ghcr.io/devcontainers/features/github-cli:1": {}
},
独自の機能の作成
独自の開発コンテナー機能を作成および公開することも簡単です。公開された機能は、サポートされているパブリックまたはプライベート コンテナー レジストリから OCI アーティファクト として保存および共有できます。現在公開されている機能のリストは、containers.dev で確認できます。
機能は、少なくとも devcontainer-feature.json と install.sh エントリポイント スクリプトを含むフォルダー内の自己完結型エンティティです。
+-- feature
| +-- devcontainer-feature.json
| +-- install.sh
| +-- (other files)
独自のパブリックまたはプライベート機能を公開するための開発コンテナー CLI の使用方法については、feature/starter リポジトリを確認してください。
機能の仕様と配布
機能は、オープンソースの Development Containers Specification の重要な部分です。機能の仕組みの詳細とその 配布 について確認できます。
開発コンテナー イメージの事前ビルド
プロジェクトを開発コンテナーで開くたびにコンテナー イメージを作成してビルドするのではなく、必要なツールを含むイメージを事前にビルドすることをお勧めします。事前ビルドされたイメージを使用すると、コンテナーの起動が速くなり、構成が簡素化され、特定のバージョンのツールにピン留めしてサプライ チェーンのセキュリティを向上させ、潜在的な破損を回避できます。GitHub Actions などの DevOps または継続的インテグレーション (CI) サービスを使用してビルドをスケジュールすることにより、イメージの事前ビルドを自動化できます。
さらに優れているのは、事前ビルドされたイメージに開発コンテナー メタデータを含めることができるため、イメージを参照すると、設定が自動的にプルされることです。
開発コンテナー CLI (または 仕様 をサポートするその他のユーティリティ (例: GitHub Action)) を使用してイメージを事前ビルドすることをお勧めします。これは、開発コンテナー機能 を含む、Dev Containers 拡張機能の最新機能と同期されているためです。イメージをビルドしたら、コンテナー レジストリ (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 を使用した場合でも CLI によって更新できます）取得されます。例として、次の Dockerfile のスニペットを考えてみてください。
LABEL devcontainer.metadata='[{ \
"capAdd": [ "SYS_PTRACE" ], \
"remoteUser": "devcontainer", \
"postCreateCommand": "yarn install" \
}]'
ボリュームの検査
Docker の名前付きボリュームを検査または変更したい状況に時々遭遇することがあります。コマンドパレット（F1）から Dev Containers: ボリュームを Dev Container でエクスプローラー... を選択することで、devcontainer.json ファイルを作成または変更せずに、VS Code を使用してこれらの内容を操作できます。
Remote Explorer でボリュームを検査することもできます。ドロップダウンで [Containers] が選択されていることを確認すると、Dev Volumes セクションが表示されます。ボリュームを右クリックすると、ボリュームの作成情報（ボリュームがいつ作成されたか、どのリポジトリがクローンされたか、マウントポイントなど）を検査できます。また、dev container 内でそれを探索することもできます。
Docker 拡張機能がインストールされている場合、Docker Explorer の Volumes セクションでボリュームを右クリックし、開発コンテナでエクスプローラー を選択できます。
拡張機能の管理
VS Code は拡張機能を 2 つの場所のいずれかで実行します。UI / クライアント側のローカル、またはコンテナ内です。テーマやスニペットなど、VS Code UI に影響を与える拡張機能はローカルにインストールされますが、ほとんどの拡張機能は特定のコンテナ内に存在します。これにより、コンテナ内の特定のタスクに必要な拡張機能のみをインストールし、新しいコンテナに接続するだけでツールチェーン全体をシームレスに切り替えることができます。
Extensions ビューから拡張機能をインストールすると、自動的に正しい場所にインストールされます。拡張機能がインストールされている場所は、カテゴリのグループ分けに基づいて判断できます。Local - Installed カテゴリと、コンテナ用のカテゴリがあります。
注: 拡張機能の作成者で、拡張機能が正しく動作しない場合や、間違った場所にインストールされる場合は、詳細についてリモート開発のサポートを参照してください。
実際にリモートで実行する必要があるローカル拡張機能は、Local - Installed カテゴリで 無効 と表示されます。インストール を選択して、リモートホストに拡張機能をインストールします。
Extensions ビューに移動し、Local - Installed タイトルバーの右側にあるクラウドボタンを使用して Dev Container にローカル拡張機能をインストール: {Name} を選択することで、ローカルにインストールされたすべての拡張機能を Dev Container 内にインストールすることもできます。これにより、ドロップダウンが表示され、コンテナにインストールするローカルにインストールされた拡張機能を選択できます。
ただし、一部の拡張機能では、コンテナに追加のソフトウェアをインストールする必要がある場合があります。問題が発生した場合は、拡張機能のドキュメントを参照して詳細を確認してください。
devcontainer.json への拡張機能の追加
拡張機能 ID のリストを追加するために devcontainer.json ファイルを手動で編集することもできますが、Extensions ビューで任意の拡張機能を右クリックして、devcontainer.json に追加 を選択することもできます。
拡張機能のオプトアウト
ベースイメージまたは Feature が、dev container にインストールしたくない拡張機能を構成している場合、マイナス記号付きで拡張機能をリストすることでオプトアウトできます。例：
{
"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 ファイルで特定の場所で実行するように強制できます。
たとえば、以下の設定では、Docker 拡張機能をローカルで実行し、Remote - SSH: 構成ファイルの編集 拡張機能をデフォルトの代わりにリモートで実行するように強制します。
"remote.extensionKind": {
"ms-azuretools.vscode-docker": [ "ui" ],
"ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}
"workspace" の代わりに "ui" の値を指定すると、拡張機能をローカルの UI/クライアント側で強制的に実行します。通常、これはテストでのみ使用する必要があります。拡張機能のドキュメントで特に指定がない限り、拡張機能を破損させる可能性があるためです。詳細については、推奨される拡張機能の場所に関するセクションを参照してください。
ポートの転送または公開
コンテナは独立した環境であるため、コンテナ内のサーバー、サービス、またはその他のリソースにアクセスする場合は、ポートをホストに「フォワード」または「公開」する必要があります。これらのポートを常に公開するようにコンテナを構成するか、一時的にフォワードするだけです。
ポートを常にフォワードする
コンテナ内のフォルダーにアタッチまたは開くときに常にフォワードしたいポートのリストは、devcontainer.json の forwardPorts プロパティを使用して指定できます。
"forwardPorts": [3000, 3001]
ウィンドウをリロード/再度開くだけで、VS Code がコンテナに接続すると設定が適用されます。
ポートを一時的にフォワードする
devcontainer.json に追加しなかったポート、または Docker Compose ファイルで公開しなかったポートにアクセスする必要がある場合は、コマンドパレット（F1）から ポートをフォワード コマンドを実行することで、セッションの期間中新しいポートを一時的にフォワードできます。
ポートを選択すると、コンテナ内のポートにアクセスするために使用する必要がある localhost ポートが通知で通知されます。たとえば、ポート 3000 でリッスンしている HTTP サーバーをフォワードした場合、localhost のポート 4123 にマッピングされたことが通知される場合があります。その後、http://localhost:4123 を使用してこのリモート HTTP サーバーに接続できます。
この同じ情報は、後でアクセスする必要がある場合に Remote Explorer の Forwarded Ports セクションで確認できます。
フォワードしたポートを VS Code に記憶させたい場合は、設定エディター（⌘, (Windows, Linux Ctrl+,)）で Remote: Restore Forwarded Ports をオンにするか、settings.json で "remote.restoreForwardedPorts": true を設定します。
ポートを公開する
Docker には、コンテナが作成されたときにポートを「公開」するという概念があります。公開されたポートは、ローカルネットワークで使用できるようにするポートと非常によく似た動作をします。アプリケーションが localhost からの呼び出しのみを受け入れる場合、ローカルマシンがネットワーク呼び出しに対して行うのと同様に、公開されたポートからの接続を拒否します。一方、フォワードされたポートは、アプリケーションに対して実際には localhost のように見えます。それぞれが異なる状況で役立ちます。
ポートを公開するには、次のいずれかを実行できます。
-
appPort プロパティを使用する:
devcontainer.jsonでイメージまたは Dockerfile を参照する場合、appPortプロパティを使用してポートをホストに公開できます。"appPort": [ 3000, "8921:5000" ] -
Docker Compose ポートマッピングを使用する: ポートマッピングは、追加のポートを公開するために
docker-compose.ymlファイルに簡単に追加できます。ports: - "3000" - "8921:5000"
いずれの場合も、設定を有効にするにはコンテナを再構築する必要があります。これを行うには、コンテナに接続しているときにコマンドパレット（F1）で Dev Containers: コンテナを再構築 コマンドを実行します。
ターミナルを開く
VS Code からコンテナでターミナルを開くのは簡単です。コンテナでフォルダーを開くと、VS Code で開く任意のターミナルウィンドウ（Terminal > New Terminal）は、ローカルではなくコンテナ内で自動的に実行されます。
この同じターミナルウィンドウから code コマンドラインを使用して、コンテナで新しいファイルまたはフォルダーを開くなど、多くの操作を実行することもできます。コマンドラインで使用できるオプションを確認するには、code --help と入力してください。
コンテナーでのデバッグ
コンテナでフォルダーを開くと、ローカルでアプリケーションを実行する場合と同じ方法で VS Code のデバッガーを使用できます。たとえば、launch.json で起動構成を選択してデバッグを開始する（F5）と、アプリケーションはリモートホストで起動し、デバッガーがそれにアタッチされます。
.vscode/launch.json で VS Code のデバッグ機能を構成する方法の詳細については、デバッグのドキュメントを参照してください。
コンテナー固有の設定
VS Code のローカルユーザー設定は、dev container に接続している場合も再利用されます。これにより、ユーザーエクスペリエンスの一貫性が保たれますが、ローカルマシンと各コンテナ間でこれらの設定の一部を変更したい場合があります。幸いなことに、コンテナに接続したら、コマンドパレット（F1）から Preferences: Open Remote Settings コマンドを実行するか、設定エディターで Remote タブを選択して、コンテナ固有の設定を設定することもできます。これらは、コンテナに接続するたびに、既存のローカル設定をオーバーライドします。
デフォルトのコンテナ固有の設定
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 を使用することもできます。コンテナを停止するには、ドロップダウンから [Containers] を選択し（存在する場合）、実行中のコンテナを右クリックして、コンテナを停止 を選択します。終了したコンテナの起動、コンテナの削除、最近使用したフォルダーの削除もできます。詳細ビューから、ポートをフォワードしたり、すでにフォワードされているポートをブラウザーで開いたりできます。
イメージをクリーンアップしたり、コンテナを一括削除したりする場合は、さまざまなオプションについて未使用のコンテナとイメージのクリーンアップを参照してください。
ドットファイル リポジトリによるパーソナライズ
ドットファイルとは、ファイル名がドット（.）で始まり、通常はさまざまなアプリケーションの構成情報を含むファイルです。開発コンテナは幅広い種類のアプリケーションをカバーできるため、これらのファイルをどこかに保存しておくと、起動および実行後にコンテナに簡単にコピーできると便利です。
これを行う一般的な方法は、これらのドットファイルを GitHub リポジトリに保存し、ユーティリティを使用してクローンして適用することです。Dev Containers 拡張機能には、これらを独自のコンテナで使用するための組み込みサポートがあります。このアイデアに慣れていない場合は、存在するさまざまなドットファイルブートストラップリポジトリをご覧ください。
使用するには、ドットファイル GitHub リポジトリを VS Code のユーザー設定（⌘, (Windows, Linux Ctrl+,)）に次のように追加します。
または 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 の pull および sync 機能がハングする可能性があります。パスフレーズなしの 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 に影響します。）
Containers に関連するアクティブな問題のリストについては、こちらを参照してください。
Docker の制限事項
Windows または Mac 用の Docker トラブルシューティングガイドを参照し、詳細については Docker サポートリソースを参照してください。
Docker 拡張機能の制限事項
WSL、Remote - Tunnels、または Remote - SSH ウィンドウから Docker または Kubernetes 拡張機能を使用している場合、Docker または Kubernetes ビューで Attach Visual Studio Code コンテキストメニューアクションを使用すると、利用可能なコンテナから再度選択するように求められます。
拡張機能の制限事項
現時点では、ほとんどの拡張機能は Dev Containers 内で変更なしで動作します。ただし、場合によっては、特定の機能で変更が必要になる場合があります。拡張機能の問題が発生した場合は、こちらで一般的な問題と解決策の概要を確認してください。これは、問題を報告するときに拡張機能の作成者に伝えることができます。
さらに、Alpine のサポートは利用可能ですが、コンテナにインストールされた一部の拡張機能は、拡張機能内のネイティブコードの glibc 依存関係が原因で動作しない場合があります。詳細については、Linux でのリモート開発の記事を参照してください。
高度なコンテナー構成
次のトピックに関する情報については、高度なコンテナ構成の記事を参照してください。
- 環境変数の追加
- 別のローカルファイルマウントの追加
- デフォルトのソースコードマウントの変更または削除
- コンテナディスクのパフォーマンスの向上
- dev container への非 root ユーザーの追加
- Docker Compose のプロジェクト名の設定
- コンテナ内からの Docker または Kubernetes の使用
- 一度に複数のコンテナへの接続
- リモート Docker Machine または SSH ホスト上のコンテナ内での開発
- Dockerfile のビルド警告の削減
- Git の認証情報をコンテナと共有する
devcontainer.json リファレンス
開発コンテナをカスタマイズし、実行中のコンテナへのアタッチ方法を制御するのに役立つファイルスキーマを確認できる、完全な devcontainer.json リファレンスがあります。
質問またはフィードバック
- Tips and Tricks または FAQ を参照してください。
- Stack Overflow で検索してください。
- 機能リクエストを追加するか、問題を報告してください。
- 他のユーザーが使用できるように Dev Container テンプレート または Feature を作成してください。
- Development Containers Specification を確認し、フィードバックを提供してください。
- ドキュメントまたは VS Code 自体に貢献してください。
- 詳細については、CONTRIBUTING ガイドを参照してください。
次のステップ
- 実行中のコンテナにアタッチ - 既に実行中の Docker コンテナにアタッチします。
- 開発コンテナを作成する - 作業環境用のカスタムコンテナを作成します。
- 高度なコンテナ - 高度なコンテナシナリオの解決策を見つけます。
- devcontainer.json リファレンス -
devcontainer.jsonスキーマを確認します。