Anpassen von Docker-Containern in Visual Studio

Sie können Ihre Containerimages anpassen, indem Sie die Dockerfile bearbeiten, die Visual Studio generiert, wenn Sie Ihrem Projekt Docker-Unterstützung hinzufügen. Ganz gleich, ob Sie einen angepassten Container über die Visual Studio IDE erstellen oder einen Build über die Befehlszeile einrichten, müssen Sie wissen, wie Visual Studio die Dockerfile verwendet, um einen Build für Ihre Projekte zu erstellen. Sie müssen diese Details kennen, weil Visual Studio aus Leistungsgründen einen speziellen Prozess für die Erstellung und Ausführung von Container-Apps verfolgt, der sich anhand der Dockerfile nicht erschließt.

Angenommen, Sie möchten eine Änderung an der Dockerfile vornehmen und die Ergebnisse sowohl in den Debug- als auch in den Produktionscontainern einsehen. In diesem Fall können Sie in der Dockerfile Befehle hinzufügen, um die erste Phase (normalerweise base) zu ändern. Weitere Informationen finden Sie unter Ändern des Containerimages für Debuggen und Produktion. Wenn Sie jedoch eine Änderung nur beim Debuggen, nicht aber für die Produktion vornehmen möchten, sollten Sie eine weitere Phase erstellen und Visual Studio mit der Buildeinstellung DockerfileFastModeStage anweisen, diese Phase für Debugbuilds zu verwenden. Weitere Informationen finden Sie unter Ändern des Containerimages nur für das Debuggen.

In diesem Artikel wird der Visual Studio-Buildprozess für Container-Apps im Detail erläutert. Anschließend erfahren Sie, wie Sie die Dockerfile so ändern können, dass sie sich sowohl auf Debug- als auch auf Produktionsbuilds auswirkt, oder auch nur auf das Debuggen.

Dockerfile-Builds in Visual Studio

Multistagebuilds

Wenn Visual Studio ein Projekt erstellt, das keine Docker-Container verwendet, ruft die IDE MSBuild auf dem lokalen Computer auf und generiert die Ausgabedateien in einem Ordner (in der Regel bin) innerhalb Ihres lokalen Projektmappenordners. Bei einem Containerprojekt berücksichtigt der Buildprozess jedoch die Anweisungen des Dockerfile zum Erstellen der Container-App. Das von Visual Studio verwendete Dockerfile ist in mehrere Stages unterteilt. Dieser Prozess basiert auf den Multistagebuilds von Docker.

Multistagebuilds sorgen für die effizientere Erstellung von Containern. Außerdem werden die Container damit kleiner, da sie nur die Komponenten enthalten, die Ihre App zur Laufzeit benötigt. Multistagebuilds werden für .NET Core-, nicht aber für .NET Framework-Projekte verwendet.

Durch einen Multistagebuild können Containerimages in Stages erstellt werden, die temporäre Images generieren. Betrachten Sie als Beispiel eine typische Dockerfile. Die erste Phase wird in der von Visual Studio generierten Dockerfile base genannt, obwohl die Tools diesen Namen nicht benötigen.

# 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

Die Zeilen der Dockerfile beginnen mit dem ASP.NET-Image aus Microsoft Container Registry (mcr.microsoft.com) und erstellen ein Zwischen-Image des Typs base, das die Ports 80 und 443 verfügbar macht und das Arbeitsverzeichnis auf /app festlegt.

Die nächste Stage ist build und sieht wie folgt aus:

# 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

Als Startpunkt für die Stage build wird offensichtlich ein anderes ursprüngliches Image aus der Registrierung verwendet (sdk anstelle von aspnet). „base“ wird hingegen nicht genutzt. Das sdk-Image verfügt über alle Buildtools und ist aus diesem Grund deutlich größer als das Image „aspnet“, das nur Laufzeitkomponenten enthält. Der Grund für die Verwendung eines separaten Images wird deutlich, wenn Sie sich den Rest des Dockerfile ansehen:

# 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"]

Die letzte Stage beginnt erneut bei base und enthält COPY --from=publish, um die veröffentlichte Ausgabe in das finale Image zu kopieren. Durch diesen Prozess wird das finale Image deutlicher kleiner, da es nicht alle Buildtools enthalten muss, die im sdk-Image vorhanden waren.

In der folgenden Tabelle sind die Phasen zusammengefasst, die in der von Visual Studio erstellten typischen Dockerfile-Datei verwendet werden:

Projektaufwärmphase

Als Projektaufwärmphase wird eine Reihe von Schritten bezeichnet, die erfolgen, wenn das Docker-Profil für ein Projekt ausgewählt wird (d. h. wenn ein Projekt geladen oder Docker-Unterstützung hinzugefügt wird), um die Leistung nachfolgender Läufe zu verbessern (F5 oder STRG+F5). Dieses Verhalten kann unter Tools>Optionen>Containertools konfiguriert werden. Es folgen die Aufgaben aufgeführt, die im Hintergrund ausgeführt werden:

• Überprüfen, ob Docker Desktop installiert ist und ausgeführt wird
• Sicherstellen, dass Docker Desktop auf das Betriebssystem des Projekts festgelegt ist
• Pullen der Images in der ersten Phase der Dockerfile (der Phase base in den meisten Dockerfiles)
• Erstellen der Dockerfile und Starten des Containers

Die Aufwärmphase findet nur im Modus Schnell statt, sodass für den aktiven Container das Volume des App-Ordners bereitgestellt wird. Das heißt, dass Änderungen an der App den Container nicht ungültig machen. Durch dieses Verhalten wird die Debugleistung deutlich verbessert und die Wartezeit für zeitintensive Aufgaben wie das Pullen großer Images verkürzt.

Aktivieren detaillierter Containertoolsprotokolle

Zu Diagnosezwecken können Sie bestimmte Containertoolsprotokolle aktivieren. Sie können diese Protokolle aktivieren, indem Sie bestimmte Umgebungsvariablen festlegen. Für einzelne Containerprojekte ist die Umgebungsvariable MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, die dann in %tmp%\Microsoft.VisualStudio.Containers.Tools protokolliert wird. Für Docker Compose-Projekte lautet die Variable MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, und sie wird in %tmp%\Microsoft.VisualStudio.DockerCompose.Tools protokolliert.

Nächste Schritte

Erfahren Sie, wie Sie die Dockerfile-Phasen verwenden, um die für das Debuggen und die Produktion verwendeten Images anzupassen, beispielsweise, wie Sie nur beim Debuggen ein Tool auf dem Image installieren. Siehe Konfigurieren von Containerimages zum Debuggen.

Zugehöriger Inhalt

• MSBuild-Eigenschaften für Containerprojekte
• Dockerfile unter Windows
• Linux-Container unter Windows