開発環境
コンテナベースのサービスを開発する環境として、ローカル環境またはリモート環境を選択できます。ローカル環境とは、開発者用ワークステーションのオペレーティングシステムのことです。ローカル環境を使用するということは、ワークステーションにインストールされたDockerを使用して、サービスコンテナをビルドおよび実行することを意味します。Dockerは、Windows、macOS、およびさまざまなLinuxディストリビューションでサポートされています。システムおよびハードウェア要件については、Dockerのインストールページを参照してください。
リモート開発環境は、開発者用ワークステーションとは異なります。SSH経由でアクセス可能なリモートマシン、開発者用ワークステーション上で実行されている仮想マシン、または開発コンテナである場合があります。リモート環境は、ローカル環境よりも利点がある場合があります。主な利点は、開発中およびサービスが本番環境で実行されているときに、同じオペレーティングシステムを使用できることです。リモート環境を使用するには、その環境内で`docker`コマンド(Docker CLI)が利用可能で機能していることを確認する必要があります。
2番目に重要な選択は、サービスを通常のプロセスとして実行してデバッグするか、コンテナ内で実行してデバッグするかです。
開発環境を選択するためのガイドライン
-
次のようなことを気にしない場合は、ローカル環境を使用してください。
- 開発とサービスコンテナ内で同じOSを使用すること。
- ローカル環境の上に必要なツールと依存関係をインストールすること。
-
リモート環境が必要な場合は、まず開発コンテナの使用を検討してください。
- Windowsでは、Windows Subsystem for Linux(WSL)を使用するのが良い選択肢です。
-
コンテナで実行されているサービスをデバッグすることは可能ですが、複雑さが増します。デフォルトでは通常のデバッグを使用し、必要な場合はコンテナ内デバッグを使用してください。
Docker拡張機能は、.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"]
...
Windows Subsystem for Linux
Windows Subsystem for Linuxは、Windowsでのコンテナベースのサービス開発に最適な選択肢です。Windows Subsystem for Linux バージョン 2(WSL 2)を強くお勧めします。Docker Desktop for Windowsは、WSL 2で動作するように更新され、WSL 2ディストリビューション内でDocker CLIを有効にするためのグラフィカル設定があります。
Docker開発にWSL 2を使用するには、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: 新しいSSHホストを追加...を実行します。プロンプトに従って、ターゲットホストへの接続を設定します。
-
コマンドRemote-SSH: ホストに接続...を実行し、ホストに接続します。
-
新しいVS Codeウィンドウが開き、ターゲットマシンのコンテキストで実行されます。パスワード認証を使用している場合は、ここでパスワードの入力を求められます。使いやすさのために、SSHキー認証を設定することを強くお勧めします。
-
拡張機能ビューで、Docker拡張機能をインストールします(リモートホスト上)。(この手順の後、リロードが必要になる場合があります)
注:Docker拡張機能を使用してDockerイメージをビルドし、ソースコードがある場合、上記のアプローチは、開発者用ワークステーションではなく、リモートホストにソースエンリストメントがあることを意味する可能性があります。Docker拡張機能をDocker Explorer機能のみに使用している場合は、これを無視できます。
ローカルLinux VM
開発者用ワークステーションで実行されているLinux仮想マシンを使用するには、リモートマシンにインストールするのと同じ方法でVMにDockerをインストールし、VS Code Remote-SSH拡張機能を使用してVMに接続する必要があります。
あるいは、開発環境内にDocker CLIのみをインストールし、Dockerコンテキストメカニズムを使用して、開発者用ワークステーションで実行されているDockerホスト(エンジン)にCLIをポイントすることもできます。このアプローチの主な懸念事項は、VMからホスト上のDockerエンジンへのネットワーク接続を確保し、安全な方法でそれを行うことです。1つのオプションは、SSHトンネリングまたはRemote - Tunnelsを開発者用ワークステーションに使用することです。別のオプションは、DockerエンジンにHTTPSポートでリッスンさせることです。VM内で実行されているDocker CLIからホストDockerエンジンを使用するには、SSHおよび公開鍵インフラストラクチャ(PKI)に精通している必要があります。ほとんどのユーザーには、仮想マシン内へのDockerのフルインストールをお勧めします。
コンテナ内でのデバッグ
Docker拡張機能は、コンテナ内で実行されている.NETおよびNode.jsベースのサービスのデバッグをサポートしています。現時点では、他のプログラミング言語はサポートされていません。
コンテナ内でのデバッグは、コンテナがプロセスよりも強力な分離メカニズムであるため、通常のデバッグよりも設定が難しい場合があります。特に、
- VS Codeプロセス内で実行されているデバッグエンジンは、デバッグ対象のサービスプロセスと通信する必要があります。コンテナ内で実行されているサービスの場合、これは共通ネットワーク(通常はDockerホストネットワーク)を介したネットワーク通信を意味します。コンテナは、デバッグエンジンがサービスプロセス(Node.js)またはコンテナ内で実行されているデバッガープロキシ(.NET)に接続するために、Dockerホストネットワーク経由で適切なポートを公開する必要があります。
- ビルド時に生成されたソースファイル情報は、ビルド環境(VS Codeが実行されている場所)のコンテキストで有効です。コンテナファイルシステムはビルド環境ファイルシステムとは異なり、ブレークポイントがヒットしたときにデバッガーが正しいソースファイルを表示するためには、ソースファイルへのパスを再マッピングする必要があります。
上記の懸念事項のため、通常は通常のデバッグを使用し、必要な場合にコンテナ内デバッグを使用することをお勧めします。
コンテナ内でのデバッグの設定方法の詳細については、ASP.NET Coreクイックスタート、Node.jsクイックスタート、およびDocker拡張機能のタスクプロパティ(docker-build
およびdocker-run
タスク)を参照してください。
次のステップ
続きを読んで詳細をご覧ください。