在 Visual Studio 中自定義 Docker 容器
您可以透過編輯 Visual Studio 在將 Docker 支援新增至專案時所產生的 Dockerfile，來自訂容器映像檔。 無論您是從Visual Studio IDE 建置自定義容器，還是設定命令行組建，都必須知道Visual Studio如何使用Dockerfile來建置專案。 您必須知道這類詳細數據，因為基於效能考慮，Visual Studio 會遵循特殊程式來建置和執行 Dockerfile 中不明顯的容器化應用程式。
假設您想在 Dockerfile 中進行變更，並查看其在除錯和生產容器中的結果。 在此情況下，您可以在 Dockerfile 中新增命令來修改第一個階段（通常是 base）。 請參閱 修改容器映射以進行偵錯和生產。 但是，如果您想要只在偵錯時進行變更，而不是生產環境，您應該建立另一個階段，並使用 DockerfileFastModeStage 建置設定告訴 Visual Studio 針對偵錯組建使用該階段。 請參閱 僅修改容器映像以進行偵錯。
本文將詳細說明容器化應用程式的Visual Studio建置程式，然後包含如何修改Dockerfile以影響偵錯和生產組建的資訊，或只用於偵錯。
Visual Studio 中的 Dockerfile 組建
注意
本節說明當您選擇 Dockerfile 容器組建類型時，Visual Studio 所使用的容器建置程式。 如果您使用 .NET SDK 組建類型，自定義選項會有所不同，而且本節中的資訊不適用。 相反地，請參閱 使用 dotnet publish 將 .NET 應用程式容器化，並使用 自定義容器中所述的屬性來設定容器建置程序。
多階段組建
當 Visual Studio 建置不使用 Docker 容器的專案時，它會在本機電腦上叫用 MSBuild，並在本機解決方案資料夾下的資料夾 （通常是 bin） 中產生輸出檔案。 不過，針對容器化專案，建置程式會考慮 Dockerfile 建置容器化應用程式的指示。 Visual Studio 使用的 Dockerfile 分成多個階段。 此程式依賴 Docker 多階段建置 功能。
多階段建置功能有助於讓建置容器的程式更有效率，並允許容器只包含應用程式在運行時間所需的位，讓容器變得更小。 多階段組建用於 .NET Core 專案，而不是 .NET Framework 專案。
多階段組建可讓容器映像在產生中繼映像的階段中建立。 例如，請考慮一個典型的 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 階段從登錄的不同原始映像開始（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 啟動以支援一般模式偵錯時，此階段會作為最後階段的基底（不使用偵錯組態時預設值）。 |
注意
只有 Linux 容器支援 aotdebug 階段。 如果在專案上啟用 原生預先部署（AOT）部署，則會在Visual Studio 2022 17.11和更新版本中使用。
項目熱身
專案熱身 是指針對專案選取 Docker 配置檔時發生的一系列步驟（也就是載入專案或新增 Docker 支援時），以改善後續執行的效能（F5 或 Ctrl+F5）。 此行為可在 Tools>Options>Container Tools下設定。 以下是在背景中執行的工作：
- 檢查 Docker Desktop 是否已安裝並執行。
- 確定 Docker Desktop 已設定為與專案相同的作業系統。
- 在 Dockerfile 的第一個階段拉取映像檔（在大多數 Dockerfile 中的
base階段）。 - 建置 Dockerfile 並啟動容器。
熱身只會在 Fast 模式中發生，因此執行中的容器具有 應用程式 資料夾磁碟區掛接。 這表示對應用程式所做的任何變更不會使容器失效。 此行為可大幅改善偵錯效能，並減少長時間執行的工作等候時間，例如提取大型映像。
啟用詳細的容器工具記錄
出於診斷目的，您可以啟用特定的容器工具日誌。 您可以藉由設定特定環境變數來啟用這些記錄。 對於單一容器專案，環境變數為 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 階段（stages）來自訂用於偵錯和生產環境的映像檔，例如，只有在用於偵錯時，才在映像檔上安裝工具。 請參閱 設定容器映射以進行偵錯。
相關內容
- 容器專案的 MSBuild 屬性。
- Windows 上的 Dockerfile
- 在 Windows 上 Linux 容器