開発環境
コンテナベースのサービスを開発する際、ローカル環境とリモート環境のどちらで開発するかを選択できます。ローカル環境とは開発者のワークステーションのオペレーティングシステムのことです。ローカル環境を使用するということは、ワークステーションにインストールされた Docker を使用してサービスコンテナをビルド・実行することを意味します。Docker は Windows、macOS、およびさまざまな Linux ディストリビューションでサポートされています。システムやハードウェアの要件については、Docker インストールページを参照してください。
リモート開発環境は、開発者のワークステーションとは異なります。SSH を介してアクセス可能なリモートマシン、開発者のワークステーション上で実行される仮想マシン、または開発コンテナなどが挙げられます。リモート環境にはローカル環境に対する利点があり、主な利点は開発時と本番環境でのサービス実行時に同じオペレーティングシステムを使用できることです。リモート環境を使用するには、docker コマンド(Docker CLI)がその環境内で利用可能かつ機能していることを確認する必要があります。
もう一つの重要な選択は、サービスを通常のプロセスとして実行してデバッグするか、コンテナ内で実行してデバッグするかです。
開発環境を選択するためのガイドライン
-
以下を気にしない場合は、ローカル環境を使用してください:
- 開発時とサービスコンテナ内で同じ OS を使用すること。
- ローカル環境上に必要なツールや依存関係をインストールすること。
-
リモート環境が必要な場合は、まず開発コンテナの使用を検討してください。
- Windows では、Windows Subsystem for Linux (WSL) が良い選択肢です。
-
コンテナ内で実行されているサービスのデバッグは可能ですが、複雑さが増します。デフォルトでは通常のデバッグを使用し、必要な場合にのみコンテナ内でのデバッグを使用してください。
Container Tools 拡張機能は、.NET、Node.js、および Python ベースのサービスのコンテナデバッグをネイティブでサポートしています。
リモート開発環境内での Docker CLI の有効化
リモート開発環境内で Docker CLI を有効にする方法は、選択するリモート環境の種類によって異なります。
開発コンテナ
開発コンテナの場合、コンテナ内の Docker CLI をローカルマシン上で実行されている Docker デーモンにリダイレクトする必要があります。
まず、Docker CLI が開発コンテナにインストールされていることを確認してください。具体的な手順は、コンテナが使用している Linux ディストリビューションによって異なります。
以下は Ubuntu ベースのディストリビューションの例です(.devcontainer/Dockerfile から)
...
&& apt-get -y install software-properties-common \
&& curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - 2>/dev/null \
&& add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable" \
&& apt-get update -y \
&& apt-get install -y docker-ce-cli \
&& apt-get install -y python python-pip \
&& pip install docker-compose \
...
次に、Docker ソケットが開発コンテナにマッピングされていることを確認してください(.devcontainer/devcontainer.json 内)
...
"runArgs": [ "-v", "/var/run/docker.sock:/var/run/docker.sock"]
...
Linux 用 Windows サブシステム
Windows Subsystem for Linux は、Windows 上でのコンテナベースのサービス開発に最適な選択肢です。Windows Subsystem for Linux version 2 (WSL 2) を強く推奨します。Windows 版 Docker Desktop は WSL 2 で動作するように更新されており、WSL 2 ディストリビューション内で Docker CLI を有効にするグラフィカルな設定があります。

WSL 2 を Docker 開発に使用するには、Windows 10 バージョン 2004 以降と、Docker Desktop for Windows バージョン 2.2.0.5 以降が必要です。
古いバージョンの WSL (WSL 1) には、ホスト上の Docker デーモンに接続する簡単な方法がありません。
リモートマシン
リモートマシンでコンテナ開発を有効にするための推奨される方法は、Docker デーモンを含む完全な Docker インストールをマシン上に行うことです。
注: Docker Desktop 製品は、物理的な Windows および macOS マシンでのみサポートされており、仮想マシンではサポートされていません。仮想マシンをリモート開発環境として使用したい場合は、Docker Engine を搭載した Linux VM を使用することをお勧めします。
リモートマシンに Docker がインストールされ動作したら、Remote Development 拡張パックに含まれる VS Code の Remote - SSH 拡張機能を使用してリモートマシンに接続し、作業できます。
-
VS Code コマンドパレット(⇧⌘P (Windows, Linux Ctrl+Shift+P))を開き、Remote-SSH: Add new SSH host... コマンドを実行します。プロンプトに従って、ターゲットホストへの接続を設定してください。
-
Remote-SSH: Connect to host... コマンドを実行し、ホストに接続します。
-
新しい VS Code ウィンドウが開き、ターゲットマシンのコンテキストで実行されます。パスワード認証を使用している場合は、ここでパスワードが要求されます。利便性のために SSH 公開鍵認証を設定することを強く推奨します。
-
拡張機能ビューで、Container Tools 拡張機能を(リモートホスト上に)インストールします(この手順の後に再読み込みが必要な場合があります)。

注: Container Tools 拡張機能を使用してコンテナイメージをビルドし、ソースコードがある場合、上記のアプローチはソースコードが開発者のワークステーションではなくリモートホスト上にあることを意味します。Container Tools 拡張機能を Container Explorer 機能のためにのみ使用している場合は、この点は無視して構いません。
ローカル Linux VM
開発者のワークステーションで実行されている Linux 仮想マシンを使用するには、リモートマシンにインストールする場合と同じ方法で VM に Docker をインストールし、VS Code Remote-SSH 拡張機能を使用して VM に接続する必要があります。
あるいは、開発環境内に Docker CLI のみをインストールし、Docker コンテキストメカニズムを使用して CLI から開発者ワークステーション上で実行されている Docker ホスト(エンジン)を指定することもできます。このアプローチにおける主な懸念事項は、VM からホスト上の Docker エンジンへのネットワーク接続を確保し、かつそれを安全に行うことです。一つの選択肢は、開発ワークステーションへの SSH トンネリング または Remote - Tunnels を使用することです。別の選択肢は、Docker エンジンを HTTPS ポートでリッスンさせることです。VM 内で実行されている Docker CLI からホストの Docker エンジンを使用するには、SSH と公開鍵インフラストラクチャ(PKI)に習熟している必要があります。ほとんどのユーザーには、仮想マシン内への完全な Docker インストールを推奨します。
コンテナ内でのデバッグ
Container Tools 拡張機能は、コンテナ内で実行されている .NET および Node.js ベースのサービスのデバッグをサポートしています。現時点では他のプログラミング言語はサポートされていません。
コンテナはプロセスよりも強力な分離メカニズムであるため、コンテナ内でのデバッグは通常のデバッグよりも設定が難しい場合があります。特に以下の点に注意してください。
- VS Code プロセス内で実行されているデバッグエンジンは、デバッグ対象のサービスプロセスと通信する必要があります。コンテナ内で実行されているサービスの場合、これは共通ネットワーク(通常は Docker ホストネットワーク)を介したネットワーク通信を意味します。デバッグエンジンがサービスプロセス(Node.js)、またはコンテナ内で実行されているデバッガープロキシ(.NET)に接続できるように、コンテナ側で適切なポートを Docker ホストネットワーク経由で公開する必要があります。
- ビルド時に生成されたソースファイル情報は、ビルド環境(VS Code が実行されている場所)のコンテキストで有効です。コンテナのファイルシステムはビルド環境のファイルシステムとは異なるため、ブレークポイントにヒットしたときにデバッガーが正しいソースファイルを表示できるように、ソースファイルへのパスを再マッピングする必要があります。
上記のような懸念事項があるため、通常は通常のデバッグを使用し、必要な場合にのみコンテナ内でのデバッグを使用することを推奨します。
コンテナ内でのデバッグの設定方法の詳細については、ASP.NET Core クイックスタート、Node.js クイックスタート、および Container Tools 拡張機能のタスクプロパティ(docker-build および docker-run タスク)を参照してください。
次のステップ
詳細については、以下をお読みください。