Visual Studio で Docker コンテナーをカスタマイズする
コンテナー イメージをカスタマイズするには、プロジェクトに Docker サポートを追加するときに Visual Studio によって生成される Dockerfile を編集します。 Visual Studio IDE からカスタマイズ済みコンテナーをビルドする場合でも、コマンドライン ビルドを設定する場合でも、プロジェクトのビルドのために Visual Studio によって Dockerfile が使用されるしくみを知っておく必要があります。 このような詳細については、Visual Studio は Dockerfile からは明らかでないコンテナー化されたアプリをビルドして実行するための特別なプロセスに従うというパフォーマンス上の理由から知っておく必要があります。
Dockerfile で変更を加え、デバッグ コンテナーと運用環境コンテナーの両方で結果を確認するとします。 この場合、Dockerfile にコマンドを追加して、最初のステージ (通常 base) を変更できます。 「デバッグと運用のためにコンテナー イメージを変更する」を参照してください。 ただし、(運用環境ではなく) デバッグ時にのみ変更を行う場合は、別のステージを作成し、DockerfileFastModeStage ビルド設定を使用して、そのステージをデバッグ ビルドに使用するように Visual Studio に指示する必要があります。 「デバッグ用にのみコンテナー イメージを変更する」を参照してください。
この記事では、コンテナー化されたアプリの Visual Studio ビルド プロセスについてある程度詳しく説明します。その後、Dockerfile を変更してデバッグ ビルドと運用環境ビルドの両方、またはデバッグ用にのみ影響を与える方法について説明します。
Visual Studio での Dockerfile ビルド
Note
このセクションでは、Dockerfile コンテナーのビルドの種類を選んだときに Visual Studio が実行するコンテナーのビルド プロセスについて説明します。 .NET SDK のビルドの種類を使う場合は異なるカスタマイズ オプションになるため、このセクションの情報は適用できません。 代わりに、「dotnet publish を使用して .NET アプリをコンテナー化する」を参照し、「コンテナーをカスタマイズする」で説明されているプロパティを使って、コンテナーのビルド プロセスを構成してください。
マルチステージ ビルド
Visual Studio では、Docker コンテナーを使用しないプロジェクトをビルドするときに、ローカル コンピューター上で MSBuild が呼び出され、ローカル ソリューション フォルダーの下のフォルダー (通常は bin) 内に出力ファイルが生成されます。 ただし、コンテナー化されたプロジェクトの場合、コンテナー化されたアプリをビルドするため、ビルド プロセスで Dockerfile の命令が考慮されます。 Visual Studio で使用される Dockerfile は、複数のステージに分割されます。 このプロセスは、Docker のマルチステージ ビルド機能に依存しています。
マルチステージ ビルド機能を使用すると、コンテナーのビルド プロセスが効率化され、実行時にアプリに必要なビットしか含めないようにすることで、コンテナーのサイズを小さくすることができます。 マルチステージ ビルドは、.NET Framework プロジェクトではなく、.NET Core プロジェクトに使用されます。
マルチステージ ビルドを使用すると、中間イメージを生成するステージでコンテナー イメージを作成できます。 たとえば、次のような一般的な Dockerfile があるとします。 最初のステージは、Visual Studio によって生成される Dockerfile では base と呼ばれますが、ツールではその名前は必要ありません。
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
Dockerfile 内の行は、Microsoft Container Registry (mcr.microsoft.com) の ASP.NET イメージから始まり、ポート 80 および 443 を公開する中間イメージ base が作成され、作業ディレクトリが /app に設定されます。
次のステージは build で、次のように表示されます。
# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim AS build
WORKDIR /src
COPY ["WebApplication43/WebApplication43.csproj", "WebApplication43/"]
RUN dotnet restore "WebApplication43/WebApplication43.csproj"
COPY . .
WORKDIR "/src/WebApplication43"
RUN dotnet build "WebApplication43.csproj" -c Release -o /app/build
build のステージは、base からの続きではなく、レジストリ (aspnet ではなく sdk) からの別の、元のイメージから開始されることがわかります。 sdk のイメージにはすべてのビルド ツールがあるため、実行時コンポーネントのみを含む aspnet イメージよりもかなり大きくなります。 別のイメージを使用する理由は、Dockerfile の残りの部分を確認すると明確になります。
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication43.csproj" -c Release -o /app/publish
# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication43.dll"]
最後のステージは、もう一度 base から始まります。発行された出力を最終イメージにコピーするための COPY --from=publish が含まれます。 このプロセスを使用すると、sdk イメージに含まれていたすべてのビルド ツールを含める必要がないため、最終的なイメージがかなり小さくなる可能性があります。
次の表は、Visual Studio によって作成される一般的な Dockerfile で使用されるステージをまとめたものです。
| 段階 | 説明 |
|---|---|
| base | ビルドされたアプリが発行されるベース ランタイム イメージを作成します。 ポートや環境変数など、実行時に使用できる必要がある設定はここで行います。 このステージは VS から高速モードで実行する場合に使用されます (デバッグ構成の既定)。 |
| build | プロジェクトはこのステージでビルドされます。 .NET SDK ベース イメージが使用されます。このイメージには、プロジェクトのビルドに必要なコンポーネントが含まれています。 |
| publish | このステージはビルド ステージから派生し、プロジェクトを発行します。プロジェクトは最終ステージにコピーされます。 |
| final | このステージではアプリを起動する方法を構成し、本番環境内または VS から通常モードで実行する場合に使用します (デバッグ構成を使用しない場合の既定)。 |
| aotdebug | このステージは、通常モードでのデバッグをサポートするために VS から起動する際の最終ステージのベースとして使用されます (デバッグ構成を使用しない場合の既定)。 |
Note
aotdebug ステージは Linux コンテナーでのみサポートされています。 プロジェクトでネイティブ Ahead Of Time (AOT) デプロイが有効になっている場合に、Visual Studio 2022 17.11 以降で使用されます。
プロジェクトのウォームアップ
プロジェクトのウォームアップとは、後続の実行 (F5 キーまたは Ctrl+F5 キー) のパフォーマンスを向上させるために、プロジェクトの Docker プロファイルが選択されたとき (つまり、プロジェクトが読み込まれたとき、または Docker のサポートが追加されたとき) に実行される一連の手順を指します。 この動作は、[ツール]>[オプション]>[コンテナー ツール] で構成できます。 バックグラウンドでは、次のタスクが実行されます。
- Docker Desktop がインストールされ、実行されていることを確認します。
- Docker Desktop がプロジェクトと同じオペレーティング システムに設定されていることを確認します。
- Dockerfile の最初のステージ (ほとんどの Dockerfile では
baseステージ) でイメージをプルします。 - Dockerfile をビルドし、コンテナーを開始します。
ウォームアップは高速モードでのみ発生するため、実行中のコンテナーには app フォルダーがボリューム マウントされています。 つまり、アプリに変更を加えてもコンテナーは無効になりません。 この動作により、デバッグのパフォーマンスが大幅に向上し、大きなイメージのプルなどの長時間実行されるタスクの待機時間が短縮されます。
詳細なコンテナー ツール ログを有効にする
診断の目的で、特定のコンテナー ツール ログを有効にできます。 これらのログを有効にするには、特定の環境変数を設定します。 単一コンテナー プロジェクトの場合、環境変数は MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED で、%tmp%\Microsoft.VisualStudio.Containers.Tools にログが記録されます。 Docker Compose プロジェクトの場合は MS_VS_DOCKER_TOOLS_LOGGING_ENABLED で、%tmp%\Microsoft.VisualStudio.DockerCompose.Tools にログされます。
警告
ログが有効で、かつ Azure 認証にトークン プロキシを使用している場合、認証資格情報がプレーン テキストとしてログに記録される場合があります。 詳しくは、「Azure 認証を構成する」をご覧ください。
次のステップ
デバッグ時のみイメージにツールをインストールする方法など、Dockerfile ステージを使用して、デバッグと運用環境で使用するイメージをカスタマイズする方法について説明します。 デバッグについては、コンテナー イメージの構成方法に関する記事を参照してください。