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
Hinweis
In diesem Abschnitt wird der Containerbuildprozess beschrieben, den Visual Studio beim Auswählen des Dockerfile-Containerbuildtyps verwendet. Wenn Sie den .NET SDK-Buildtyp verwenden, unterscheiden sich die Anpassungsoptionen und die Informationen in diesem Abschnitt gelten nicht. Lesen Sie stattdessen Containerisieren einer .NET-Anwendung mit dotnet publish und verwenden Sie die unter Anpassen Ihres Containers beschriebenen Eigenschaften, um den Containerbuildprozess zu konfigurieren.
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:
| Phase | Beschreibung |
|---|---|
| base | Erstellt das Basislaufzeitimage, in dem die integrierte App veröffentlicht wird. Einstellungen, die zur Laufzeit verfügbar sein müssen, finden Sie hier, z. B. Ports und Umgebungsvariablen. Diese Phase wird verwendet, wenn sie über VS im Schnellmodus ausgeführt wird (Standard für die Debugkonfiguration). |
| build | Das Projekt wird in dieser Phase erstellt. Das .NET SDK-Basisimage wird verwendet, das die Komponenten enthält, die zum Erstellen Ihres Projekts erforderlich sind. |
| Veröffentlichen | Diese Phase wird von der Erstellungsphase abgeleitet und veröffentlicht Ihr Projekt, das in die letzte Phase kopiert wird. |
| final | In dieser Phase wird konfiguriert, wie die App gestartet und in der Produktion oder beim Ausführen von VS im regulären Modus verwendet wird (Standardeinstellung, wenn die Debugkonfiguration nicht verwendet wird). |
| aotdebug | Diese Phase wird als Basis für die letzte Phase beim Starten von VS verwendet, um das Debuggen im regulären Modus zu unterstützen (Standardeinstellung, wenn die Debugkonfiguration nicht verwendet wird). |
Hinweis
Die aotdebug Phase wird nur für Linux-Container unterstützt. Sie wird in Visual Studio 2022 17.11 und höher verwendet, wenn die systemeigene AOT-Bereitstellung (Ahead Of Time) für das Projekt aktiviert ist.
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
basein 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.
Warnung
Wenn die Protokollierung aktiviert ist und Sie einen Tokenproxy für die Azure-Authentifizierung verwenden, können Authentifizierungsanmeldeinformationen als Nur-Text protokolliert werden. Weitere Informationen finden Sie unter Konfigurieren der Azure-Authentifizierung.
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.