Anpassen von Containerimages für das Debuggen
Anmerkung
In diesem Abschnitt wird beschrieben, wie Sie Ihre Docker-Container anpassen können, wenn Sie den Dockerfile-Containerbuildtyp auswählen. Wenn Sie den .NET SDK-Buildtyp verwenden, unterscheiden sich die Anpassungsoptionen, und die meisten Informationen in diesem Abschnitt gelten nicht. Lesen Sie stattdessen Containerisierung einer .NET-Anwendung mit dotnet publish.
Beim Erstellen in der Debug--Konfiguration nimmt Visual Studio mehrere Optimierungen vor, die zur Verbesserung der Leistung des Buildprozesses für containerisierte Projekte beitragen. Der Buildprozess für containerisierte Apps ist nicht so einfach wie das Ausführen der in der Dockerfile beschriebenen Schritte. Das Erstellen in einem Container ist langsamer als das Erstellen auf dem lokalen Computer. Wenn Sie also für den Build die Debugkonfiguration nutzen, erstellt Visual Studio Ihre Projekte auf dem lokalen Computer und gibt den Ausgabeordner dann für den Container frei, indem das Volume eingebunden wird. Ein Build mit aktivierter Optimierung wird als Fast Modusbuild bezeichnet.
In Fast-Modus ruft Visual Studio docker build mit einem Argument auf, das Docker angibt, nur die erste Phase in der Dockerfile-Datei (normalerweise die base Phase) zu erstellen. Sie können dies ändern, indem Sie die MSBuild-Eigenschaft DockerfileFastModeStagefestlegen, die unter Containertools MSBuild-Eigenschaftenbeschrieben wird. Visual Studio behandelt den Rest des Prozesses, ohne den Inhalt der Dockerfile-Datei zu berücksichtigen. Wenn Sie Ihre Dockerfile ändern, z. B. um die Containerumgebung anzupassen oder zusätzliche Abhängigkeiten zu installieren, sollten Sie Ihre Änderungen im ersten Schritt platzieren. Alle benutzerdefinierten Schritte, die in den build, publishoder final Phasen von Dockerfile platziert werden, werden nicht ausgeführt.
Diese Leistungsoptimierung tritt normalerweise nur auf, wenn Sie die konfiguration Debug erstellen. In der Release--Konfiguration erfolgt der Build im Container, wie in der Dockerfile-Datei angegeben. Sie können dieses Verhalten für die Releasekonfiguration aktivieren, indem Sie ContainerDevelopmentMode auf Fast in der Projektdatei festlegen:
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<ContainerDevelopmentMode>Fast</ContainerDevelopmentMode>
</PropertyGroup>
Wenn Sie die Leistungsoptimierung für alle Konfigurationen deaktivieren und gemäß der Angabe im Dockerfile bauen möchten, legen Sie die Eigenschaft ContainerDevelopmentMode wie folgt auf Regular in der Projektdatei fest.
<PropertyGroup>
<ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>
Um die Leistungsoptimierung wiederherzustellen, entfernen Sie die Eigenschaft aus der Projektdatei.
Wenn Sie mit dem Debuggen beginnen (F5), wird ein zuvor gestarteter Container nach Möglichkeit wiederverwendet. Wenn Sie den vorherigen Container nicht wiederverwenden möchten, können Sie den Befehl Erstellen oder den Befehl Bereinigen in Visual Studio verwenden, damit Visual Studio einen neuen Container verwendet.
Der Prozess der Ausführung des Debuggers hängt vom Typ des Projekt- und Containerbetriebssystems ab:
| Szenario | Debuggerprozess |
|---|---|
| .NET Core-Apps (Linux-Container) | Visual Studio lädt vsdbg herunter und ordnet ihn dem Container zu, dann wird es mit Ihrem Programm und Ihren Argumenten aufgerufen (d. h. dotnet webapp.dll), und dann verbindet sich der Debugger mit dem Prozess. |
| .NET Core-Apps (Windows-Container) | Visual Studio verwendet onecoremsvsmon und ordnet es dem Container zu, führt es als Einstiegspunkt aus und verbindet sich dann damit und hängt sich an das Programm an. |
| .NET Framework-Apps | Visual Studio verwendet msvsmon und ordnet ihn dem Container zu, führt ihn als Teil des Einstiegspunkts aus, an dem Visual Studio eine Verbindung damit herstellen kann, und fügt es an das Programm an. Dies ähnelt der Vorgehensweise, wie Sie das Remotedebugging normalerweise auf einem anderen Computer oder virtuellen Computer einrichten würden. |
Informationen zu vsdbg.exefinden Sie unter Offroad-Debugging von .NET Core unter Linux und OS X von Visual Studio.
Ändern des Containerimages für Debugging und Produktion
Um das Containerimage sowohl für das Debuggen als auch für die Produktion zu ändern, ändern Sie die base Phase. Fügen Sie Ihre benutzerdefinierten Anpassungen des Dockerfile im Abschnitt der Phase „base“ hinzu, normalerweise der erste Abschnitt im Dockerfile. Informationen zu Dockerfile-Befehlen finden Sie in der Docker-Dokumentation unter der Dockerfile-Referenz .
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# <add your commands here>
# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["WebApplication3/WebApplication3.csproj", "WebApplication3/"]
RUN dotnet restore "WebApplication3/WebApplication3.csproj"
COPY . .
WORKDIR "/src/WebApplication3"
RUN dotnet build "WebApplication3.csproj" -c Release -o /app/build
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication3.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", "WebApplication3.dll"]
Containerimage nur zum Debuggen ändern
Sie können Ihre Container auf bestimmte Weise anpassen, um beim Debuggen zu helfen, z. B. das Installieren von Etwas für Diagnosezwecke, ohne dass sich dies auf Produktionsbuilds auswirkt.
Um den Container nur für das Debuggen zu ändern, erstellen Sie eine Phase, und verwenden Sie dann die MSBuild-Eigenschaft DockerfileFastModeStage, um Visual Studio anweisen, die angepasste Phase beim Debuggen zu verwenden. Informationen zu Dockerfile-Befehlen finden Sie in der Dockerfile-Referenz in der Docker-Dokumentation.
Anmerkung
Die hier aufgeführten Anweisungen gelten für den Einzelcontainerfall. Sie können auch dieselbe Funktion für mehrere Container mit Docker Compose ausführen, aber die für Docker Compose erforderlichen Techniken unterscheiden sich geringfügig. Beispielsweise wird die Phase durch eine Einstellung in der dockercompose.debug.yml Datei gesteuert.
Im folgenden Beispiel installieren wir das Paket procps-ng, aber nur im Debugmodus. Dieses Paket stellt den Befehl pidofzur Verfügung, den Visual Studio benötigt (bei Zielsetzungen auf .NET 5 und frühere Versionen), der jedoch nicht im hier verwendeten Mariner-Image enthalten ist. Die Phase, die wir für das Debuggen im schnellen Modus verwenden, ist debug, eine benutzerdefinierte Phase, die hier definiert ist. Die Phase für den schnellen Modus muss nicht von der build- oder publish-Phase erben; sie kann direkt von der base-Phase erben, da Visual Studio ein Volume einbindet, das alles enthält, was für das Ausführen der App erforderlich ist, wie weiter oben in diesem Artikel beschrieben.
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:6.0-cbl-mariner2.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM base AS debug
RUN tdnf install procps-ng -y
# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:6.0-cbl-mariner2.0 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication1.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", "WebApplication1.dll"]
Fügen Sie in der Projektdatei diese Einstellung hinzu, um Visual Studio anweisen, beim Debuggen die benutzerdefinierte Phase debug zu verwenden.
<PropertyGroup>
<!-- other property settings -->
<DockerfileFastModeStage>debug</DockerfileFastModeStage>
</PropertyGroup>
Anpassen von Images beim Debuggen mit AOT-Bereitstellung
Zur Unterstützung der nativen AOT-Bereitstellung wird der GNU-Debugger (GDB) installiert, aber nur auf dem Image, das beim Debuggen verwendet wird, nicht das endgültige Laufzeitimage. Die Dockerfile-Datei enthält ein Buildargument LAUNCHING_FROM_VS, das true oder falsesein kann. Wenn true, wird die aotdebug Stufe verwendet, bei der GDB installiert wird. Beachten Sie, dass Visual Studio nur systemeigene AOT und GDB für Linux-Container unterstützt.
# These ARGs allow for swapping out the base used to make the final image when debugging from VS
ARG LAUNCHING_FROM_VS
# This sets the base image for final, but only if LAUNCHING_FROM_VS has been defined
ARG FINAL_BASE_IMAGE=${LAUNCHING_FROM_VS:+aotdebug}
# ... (other stages omitted)
# This stage is used as the base for the final stage when launching from VS to support debugging in regular mode (Default when not using the Debug configuration)
FROM base as aotdebug
USER root
# Install GDB to support native debugging
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
gdb
USER app
# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM ${FINAL_BASE_IMAGE:-mcr.microsoft.com/dotnet/runtime-deps:8.0} AS final
WORKDIR /app
EXPOSE 8080
COPY --from=publish /app/publish .
ENTRYPOINT ["./WebApplication1"]
Sie können aotstage im Dockerfile verwenden, um das zur Debugzeit verwendete Image anzupassen, ohne das endgültige Image zu beeinflussen, das nicht beim Start aus Visual Studio, sondern in der Produktion verwendet wird. Sie können z. B. ein Tool nur für die Verwendung beim Debuggen installieren.