Anpassen von Docker-Containern in Visual Studio
Sie können Ihre Containerimages anpassen, indem Sie die Dockerfile-Datei bearbeiten, die Visual Studio generiert, wenn Sie Ihrem Projekt Docker-Unterstützung hinzufügen. Ganz gleich, ob Sie einen benutzerdefinierten Container aus der Visual Studio-IDE erstellen oder einen Befehlszeilenbuild einrichten, sie müssen wissen, wie Visual Studio die Dockerfile zum Erstellen Ihrer Projekte verwendet. Sie müssen solche Details kennen, da Visual Studio aus Leistungsgründen einem speziellen Prozess zum Erstellen und Ausführen von containerisierten Apps folgt, die aus der Dockerfile-Datei nicht offensichtlich sind.
Angenommen, Sie möchten eine Änderung in der Dockerfile vornehmen und die Ergebnisse sowohl im Debuggen als auch in Produktionscontainern anzeigen. In diesem Fall können Sie Befehle in der Dockerfile-Datei hinzufügen, um die erste Phase zu ändern (in der Regel base). Weitere Informationen finden Sie unter Ändern des Containerimages für das Debuggen und die Produktion. Wenn Sie jedoch nur beim Debuggen, aber nicht bei der Produktion eine Änderung vornehmen möchten, sollten Sie eine weitere Phase erstellen und die DockerfileFastModeStage Buildeinstellung verwenden, um Visual Studio anzuweisen, 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 containerisierte Apps ausführlich erläutert. Anschließend enthält er Informationen zum Ändern der Dockerfile-Datei, um sowohl das Debuggen als auch die Produktionsbuilds oder nur für das Debuggen zu beeinflussen.
Dockerfile-Builds in Visual Studio
Anmerkung
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 Containerize a .NET app with dotnet publish und verwenden Sie die im Abschnitt Customize your container beschriebenen Eigenschaften, um den Erstellungsprozess des Containers zu konfigurieren.
Mehrstufiger Build
Wenn Visual Studio ein Projekt erstellt, das keine Docker-Container verwendet, ruft es MSBuild auf dem lokalen Computer auf und generiert die Ausgabedateien in einem Ordner (in der Regel bin) unter Ihrem lokalen Lösungsordner. Bei einem containerisierten Projekt berücksichtigt der Buildprozess jedoch die Anweisungen der Dockerfile zum Erstellen der containerisierten App. Die Dockerfile, die Visual Studio verwendet, ist in mehrere Stufen unterteilt. Dieser Prozess basiert auf dem Multistage-Build--Feature von Docker.
Das Mehrstufige Buildfeature trägt dazu bei, den Prozess des Erstellens von Containern effizienter zu gestalten und Container zu verkleinern, indem sie nur die Bits enthalten können, die Ihre App zur Laufzeit benötigt. Der Multistage-Build wird für .NET Core-Projekte und nicht für .NET Framework-Projekte verwendet.
Mit dem Mehrstufigen Build können Containerimages in Phasen erstellt werden, die Zwischenimages erzeugen. Betrachten Sie als Beispiel eine typische Dockerfile-Datei. Die erste Phase wird in der von Visual Studio generierten Dockerfile-Datei als base bezeichnet, obwohl die Tools diesen Namen nicht erfordern.
# 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 in der Dockerfile beginnen mit dem ASP.NET Image aus der Microsoft Container Registry (mcr.microsoft.com) und erstellen ein Zwischenabbild base, das die Ports 80 und 443 verfügbar macht, und legt das Arbeitsverzeichnis auf /appfest.
Die nächste Stufe ist build, die wie folgt angezeigt wird:
# 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 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 aus diesem Grund ist es viel größer als das Aspnet-Image, das nur Laufzeitkomponenten enthält. Der Grund für die Verwendung eines separaten Images wird deutlich, wenn Sie sich den Rest der 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 Phase beginnt erneut von baseund enthält die COPY --from=publish, um die veröffentlichte Ausgabe in das endgültige Bild zu kopieren. Dieser Prozess ermöglicht es, dass das endgültige Image viel kleiner ist, da es nicht alle Buildtools enthalten muss, die sich im sdk-Image befanden.
In der folgenden Tabelle sind die Phasen zusammengefasst, die in der von Visual Studio erstellten typischen Dockerfile-Datei verwendet werden:
| Stage | 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 es über Visual Studio 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). |
Anmerkung
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 native Ahead-of-time-Bereitstellung (AOT) für das Projekt aktiviert ist.
Projektaufwärmphase
Project-Warmup- bezieht sich auf eine Reihe von Schritten, die auftreten, 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 der nachfolgenden Ausführung zu verbessern (F5 oder STRG+F5). Dieses Verhalten kann unter Extras>Optionen>Containertools konfiguriert werden. Hier sind die Aufgaben, die im Hintergrund ausgeführt werden:
- Überprüfen Sie, ob Docker Desktop installiert und ausgeführt wird.
- Stellen Sie sicher, dass Docker Desktop auf dasselbe Betriebssystem wie das Projekt festgelegt ist.
- Pullen der Images in der ersten Stage des Dockerfile (in den meisten Dockerfiles Stage
base) - Erstellen Sie das Dockerfile und starten Sie den Container.
Die Aufwärmphase findet nur im Modus Schnell statt, wodurch für den aktiven Container das Volume des Ordners app bereitgestellt wird. Dies bedeutet, dass änderungen an der App den Container nicht ungültig machen. Dieses Verhalten verbessert die Debuggingleistung erheblich und verringert die Wartezeit für lange ausgeführte Aufgaben, z. B. das Ziehen großer Bilder.
Aktivieren detaillierter Protokolle für Containertools
Für Diagnosezwecke können Sie bestimmte Protokolldateien der Container-Tools 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. Bei Docker Compose-Projekten ist es MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, die sich dann in %tmp%\Microsoft.VisualStudio.DockerCompose.Toolsanmeldet.
Warnung
Wenn die Protokollierung aktiviert ist und Sie einen Tokenproxy für die Azure-Authentifizierung verwenden, können Authentifizierungsanmeldeinformationen als Nur-Text protokolliert werden. Siehe 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, z. B. wie Sie ein Tool nur beim Debuggen auf dem Image installieren. Weitere Informationen finden Sie unter Konfigurieren von Containerimages für das Debuggen.