次の方法で共有

Visual Studio でコンテナーをカスタマイズする

コンテナー のサポートをプロジェクトに追加するときに Visual Studio によって生成される Dockerfile を編集することで、コンテナー イメージをカスタマイズできます。 Visual Studio IDE からカスタマイズされたコンテナーをビルドする場合でも、コマンドライン ビルドを設定する場合でも、Visual Studio で Dockerfile を使用してプロジェクトをビルドする方法を知る必要があります。 パフォーマンス上の理由から、Visual Studio は Dockerfile からは明らかではないコンテナー化されたアプリをビルドして実行するための特別なプロセスに従うため、このような詳細を知る必要があります。

Dockerfile に変更を加え、デバッグコンテナーと運用コンテナーの両方で結果を確認するとします。 その場合は、Dockerfile にコマンドを追加して、最初のステージ (通常は base) を変更できます。 デバッグと運用については、コンテナー イメージの変更に関するページを参照してください。 ただし、デバッグ時にのみ変更を加えるが、運用環境では行わない場合は、別のステージを作成し、 ContainerFastModeStage ビルド設定を使用して、デバッグ ビルドにそのステージを使用するように Visual Studio に指示する必要があります。 デバッグについては、「コンテナー イメージの変更のみ」を参照してください。

Dockerfile に変更を加え、デバッグコンテナーと運用コンテナーの両方で結果を確認するとします。 その場合は、Dockerfile にコマンドを追加して、最初のステージ (通常は base) を変更できます。 デバッグと運用については、コンテナー イメージの変更に関するページを参照してください。 ただし、デバッグ時にのみ変更を加えるが、運用環境では行わない場合は、別のステージを作成し、 DockerfileFastModeStage ビルド設定を使用して、デバッグ ビルドにそのステージを使用するように Visual Studio に指示する必要があります。 デバッグについては、「コンテナー イメージの変更のみ」を参照してください。

この記事では、コンテナー化されたアプリの Visual Studio ビルド プロセスについて詳しく説明します。その後、デバッグビルドと実稼働ビルドの両方に影響を与えるか、デバッグ用に Dockerfile を変更する方法に関する情報が含まれています。

[前提条件]

[前提条件]

Visual Studio での Dockerfile ビルド

注

このセクションでは、Dockerfile コンテナーのビルドの種類を選択するときに Visual Studio で使用されるコンテナー ビルド プロセスについて説明します。 .NET SDK ビルドの種類を使用している場合、カスタマイズ オプションは異なり、このセクションの情報は適用されません。 代わりに、「 dotnet 発行を使用して .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:8.0 AS base
USER $APP_UID
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

Dockerfile の行は、Microsoft Container Registry (mcr.microsoft.com) の ASP.NET イメージで始まり、ポート 8080 と 8081 を公開する中間イメージ base を作成し、作業ディレクトリを /appに設定します。

.NET 7 以降を対象としている場合、 USER $APP_UID 行が表示され、環境変数 APP_UIDから取得したユーザー名を持つ管理者特権なしで実行するようにコンテナーが設定されます。 ポートは 80 と 443 ではなく 8080 と 8081 であり、管理者特権が必要です。

次のステージは buildで、次のように表示されます。

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:8.0 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 ステージは、基本から続行するのではなく、レジストリとは異なる元のイメージ (sdkではなくaspnet) から開始されていることがわかります。 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 で使用されるステージをまとめたものです。

段階 説明
ベース ビルドされたアプリが発行されるベース ランタイム イメージを作成します。 実行時に使用できる必要がある設定は、ポートや環境変数など、ここで行います。 このステージは、VS から高速モードで実行する場合に使用されます (デバッグ構成の既定)。
ビルド プロジェクトは、このステージでビルドされます。 .NET SDK 基本イメージが使用されます。このイメージには、プロジェクトのビルドに必要なコンポーネントが含まれています。
パブリッシュ このステージはビルド ステージから派生し、プロジェクトを発行します。プロジェクトは最終ステージにコピーされます。
最終的な このステージでは、アプリを起動する方法を構成し、運用環境または VS から通常モードで実行する場合に使用します (デバッグ構成を使用しない場合は既定値)。
aotdebug このステージは、通常モードでのデバッグをサポートするために VS から起動する際の最終ステージのベースとして使用されます (デバッグ構成を使用しない場合は既定値)。

注

aotdebug ステージは、Linux コンテナーでのみサポートされます。 プロジェクトで ネイティブの Ahead Of Time (AOT) デプロイ が有効になっている場合は、Visual Studio 2022 17.11 以降で使用されます。

プロジェクトのウォームアップ

プロジェクトウォームアップ とは、後続の実行 (F5 または Ctrl+F5) のパフォーマンスを向上させるために、プロジェクトに対してコンテナー プロファイルが選択されたとき (つまり、プロジェクトが読み込まれるか、コンテナーのサポートが追加されたとき) に発生する一連の手順を指します。

この動作は、[ツール>オプション] ウィンドウの [>] で構成できます。 バックグラウンドで実行されるタスクを次に示します。

  • コンテナー ランタイム (Docker Desktop または Podman) がインストールされ、実行されていることを確認します。
  • Docker Desktop がプロジェクトと同じオペレーティング システムに設定されていることを確認します。 (このチェックは、Linux コンテナーのみをサポートする Podman には適用されません)。
  • Dockerfile の最初のステージ (ほとんどの Dockerfile の base ステージ) でイメージをプルします。
  • Dockerfile をビルドし、コンテナーを開始します。

この動作は、 Tools>Options>Container Tools で構成できます。 バックグラウンドで実行されるタスクを次に示します。

  • Docker Desktop がインストールされ、実行されていることを確認します。
  • Docker Desktop がプロジェクトと同じオペレーティング システムに設定されていることを確認します。
  • Dockerfile の最初のステージ (ほとんどの Dockerfile の base ステージ) でイメージをプルします。
  • Dockerfile をビルドし、コンテナーを開始します。

ウォームアップは 高速 モードでのみ行われるため、実行中のコンテナーには アプリ フォルダーのボリュームがマウントされています。 つまり、アプリを変更してもコンテナーは無効になりません。 この動作により、デバッグのパフォーマンスが大幅に向上し、大規模なイメージのプルなどの実行時間の長いタスクの待機時間が短縮されます。

詳細なコンテナー ツール ログを有効にする

診断目的で、特定のコンテナー ツール ログを有効にすることができます。 これらのログを有効にするには、特定の環境変数を設定します。 単一コンテナプロジェクトの場合、環境変数は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 ステージを使用してデバッグと運用に使用するイメージをカスタマイズする方法について説明します。たとえば、デバッグ時にのみイメージにツールをインストールする方法について説明します。 デバッグ用のコンテナー イメージの構成を参照してください。

関連コンテンツ

  • Last updated on