Anpassen von Docker-Containern in Visual Studio

  • Artikel

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.

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:

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:

FROM build AS publish
RUN dotnet publish "WebApplication43.csproj" -c Release -o /app/publish

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.

MSBuild

Hinweis

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 Informationen in diesem Artikel gelten nicht. Siehe stattdessen Containerisierung einer .NET-Anwendung mit dotnet publish.

Dockerfiles, die von Visual Studio für .NET Framework-Projekte (und für .NET Core-Projekte, die mit älteren Versionen als Update 4 von Visual Studio 2017 erstellt wurden) erstellt werden, entsprechen nicht dem Multistagetyp. Mit den Schritten in diesen Dockerfiles wird der Code nicht kompiliert. Wenn Visual Studio ein .NET Framework-Dockerfile erstellt, kompiliert die IDE stattdessen zuerst das Projekt mithilfe von MSBuild. Wenn dieser Vorgang erfolgreich ist, erstellt Visual Studio anschließend das Dockerfile, wodurch einfach die Buildausgabe von MSBuild in das resultierende Docker-Image kopiert wird. Da die Schritte zum Kompilieren des Codes nicht im Dockerfile enthalten sind, können Sie .NET Framework-Dockerfiles nicht mithilfe von docker build über die Befehlszeile erstellen. Sie sollten MSBuild verwenden, um diese Projekte zu erstellen.

Zum Erstellen eines Images für ein einzelnes Docker-Containerprojekt können Sie MSBuild mit der Befehlsoption /t:ContainerBuild verwenden. Dieser Befehl weist MSBuild an, einen Build für das Ziel ContainerBuild und nicht für das Standardziel Build zu erstellen. Beispiel:

MSBuild MyProject.csproj /t:ContainerBuild /p:Configuration=Release

Die Ausgabe ähnelt der, die im Fenster Ausgabe angezeigt wird, wenn Sie eine Projektmappe mit der IDE Visual Studio erstellen. Verwenden Sie immer /p:Configuration=Release, da die Ergebnisse beim Erstellen mit der Debugkonfiguration möglicherweise nicht Ihren Erwartungen entsprechen, wenn Visual Studio die Multistageoptimierung für Builds verwendet. Siehe Debuggen.

Wenn Sie ein Docker Compose-Projekt verwenden, nutzen Sie den Befehl zum Erstellen von Images:

msbuild /p:SolutionPath=<solution-name>.sln /p:Configuration=Release docker-compose.dcproj

Debuggen

Hinweis

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. Siehe stattdessen Containerisierung einer .NET-Anwendung mit dotnet publish.

Beim Erstellen von Builds in der Konfiguration Debuggen führt Visual Studio mehrere Optimierungen durch, um die Leistung des Buildprozesses für Containerprojekte zu erhöhen. Der Buildprozess für Container-Apps ist komplexer, sodass nicht einfach die in der Dockerfile beschriebenen Schritte ausgeführt werden können. Ein Build in einem Container ist langsamer als ein Build auf einem 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 dieser Optimierung wird auch als Schnellmodusbuild bezeichnet.

Im Schnell-Modus ruft Visual Studio docker build mit einem Argument auf, das Docker anweist, nur die erste Stage in der Dockerfile zu erstellen (normalerweise die base-Stage). Sie können dies ändern, indem Sie die MSBuild-Eigenschaft festlegen, DockerfileFastModeStage, die unter den Containertools MSBuild-Eigenschaften beschrieben wird. Die restlichen Schritte führt Visual Studio durch, ohne den Inhalt des Dockerfile zu beachten. Wenn Sie das Dockerfile ändern, um beispielsweise die Containerumgebung anzupassen oder zusätzliche Abhängigkeiten zu installieren, sollten Sie die Änderungen in der ersten Stage ablegen. Wenn benutzerdefinierte Schritte in den Stages build, publish und final der Dockerfile hinterlegt werden, werden diese nicht ausgeführt.

Diese Leistungsoptimierung wird nur durchgeführt, wenn Sie für den Build die Debugkonfiguration verwenden. In der Releasekonfiguration findet der Build wie im Dockerfile angegeben im Container statt.

Wenn Sie die Leistungsoptimierung deaktivieren und den Build wie im Dockerfile angegeben ausführen möchten, legen Sie die Eigenschaft ContainerDevelopmentMode in der Projektdatei wie folgt auf Regular fest:

<PropertyGroup>
   <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>

Wenn Sie die Leistungsoptimierung wiederherstellen möchten, entfernen Sie die Eigenschaft aus der Projektdatei.

Wenn Sie mit dem Debuggen beginnen (F5), wird nach Möglichkeit ein zuvor gestarteter Container wiederverwendet. Wenn Sie den vorherigen Container nicht wiederverwenden möchten, können Sie in Visual Studio die Befehle Rebuild (Neu erstellen) oder Bereinigen verwenden, um zu erzwingen, dass Visual Studio einen neuen Container verwendet.

Die Ausführung des Debuggers hängt von der Art des Projekts und dem Containerbetriebssystem ab:

Szenario Debuggerprozess
.NET Core-Apps (Linux-Container) Visual Studio lädt vsdbg herunter und ordnet es dem Container zu. Dann wird es mit Ihrem Programm und Argumenten (d. h. dotnet webapp.dll) aufgerufen, und anschließend wird der Debugger an den Prozess angefügt.
.NET Core-Apps (Windows-Container) Visual Studio verwendet onecoremsvsmon, ordnet es dem Container zu und führt es als Einstiegspunkt aus. Dann stellt Visual Studio eine Verbindung damit her und fügt es an das Programm an. Dies ähnelt der Vorgehensweise beim Einrichten des Remotedebuggens auf einem anderen oder virtuellen Computer.
.NET Framework-Apps Visual Studio verwendet msvsmon, ordnet es dem Container zu, führt es als Einstiegspunkt aus, an dem sich Visual Studio damit verbinden kann, und fügt es an das Programm an.

Informationen zu vsdbg.exe finden Sie unter Offroad-Debuggen von .NET Core unter Linux und OSX in Visual Studio.

Ändern des Containerimages für Debuggen und Produktion

Um das Containerimage sowohl für das Debuggen als auch für die Produktion zu ändern, bearbeiten Sie die Phase base. Fügen Sie Ihre benutzerdefinierten Anpassungen der Dockerfile im Abschnitt der Phase „base“ hinzu, normalerweise der erste Abschnitt in der Dockerfile. Informationen zu den Dockerfile-Befehlen finden Sie in der Docker-Dokumentation in der Dockerfile-Referenz.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# <add your commands here>

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

FROM build AS publish
RUN dotnet publish "WebApplication3.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]

Ändern des Containerimages nur für das Debuggen

Dieses Szenario trifft zu, wenn Sie zur Unterstützung des Debugprozesses Maßnahmen mit Ihren Containern umsetzen möchten, z. B. die Installation von Diagnosefunktionen, die aber nicht in den Produktionsbuilds installiert werden sollen.

Um den Container nur für das Debuggen zu ändern, erstellen Sie eine Phase. Weisen Sie Visual Studio dann mit der MSBuild-Eigenschaft DockerfileFastModeStage an, Ihre benutzerdefinierte Phase beim Debuggen zu verwenden. Informationen zu den Dockerfile-Befehlen finden Sie in der Docker-Dokumentation in der Dockerfile-Referenz.

Im folgenden Beispiel installieren wir das Paket procps-ng, allerdings nur im Debugmodus. Dieses Paket liefert den Befehl pidof, den Visual Studio benötigt, der aber in dem hier verwendeten Mariner-Image nicht enthalten ist. Die Phase, die wir für das Debuggen im schnellen Modus verwenden, ist debug, eine hier definierte benutzerdefinierte Phase. Die Phase im schnellen Modus muss nicht von der Phase build oder publish erben. Sie kann direkt von der Phase base erben, da Visual Studio ein Volume einbindet, das alles enthält, was für die Ausführung der App benötigt wird, wie bereits in diesem Artikel beschrieben.

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

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

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

FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

Fügen Sie der Projektdatei diese Einstellung hinzu, um Visual Studio anzuweisen, beim Debuggen Ihre benutzerdefinierte Phase debug zu verwenden.

  <PropertyGroup>
     <!-- other property settings -->
     <DockerfileFastModeStage>debug</DockerfileFastModeStage>
  </PropertyGroup>

Die nächsten Abschnitte enthalten Informationen, die in bestimmten Fällen nützlich sein können, z. B. wenn Sie einen anderen Einstiegspunkt angeben möchten oder Ihre App für SSL aktiviert ist und Sie etwas ändern, das sich auf die Handhabung der SSL-Zertifikate auswirken könnte.

Ausführen des Builds über die Befehlszeile

Wenn Sie ein Containerprojekt mit einer Dockerfile außerhalb von Visual Studio erstellen möchten, können Sie docker build, MSBuild, dotnet build oder dotnet publish verwenden, um von der Befehlszeile aus zu erstellen.

Wenn Sie den .NET SDK-Buildtyp verwenden, verfügen Sie nicht über eine Dockerfile, sodass Sie docker build nicht verwenden können. Verwenden Sie stattdessen MSBuild, dotnet build oder dotnet publish, um von der Befehlszeile aus zu erstellen.

Docker-Build verwenden

Wenn Sie eine Projektmappe für Container über die Befehlszeile erstellen möchten, können Sie in der Regel den Befehl docker build <context> für jedes Projekt in der Projektmappe verwenden. Dabei müssen Sie das Argument für den Buildkontext angeben. Der Buildkontext eines Dockerfile auf dem lokalen Computer ist der Ordner, der als Arbeitsordner zum Generieren des Images verwendet wird. Das kann beispielsweise der Ordner sein, aus dem Sie Dateien kopieren und in den Container einfügen. Verwenden Sie in .NET Core-Projekten den Ordner mit der Projektmappendatei (.sln). Dieses Argument wird als relativer Pfad angegeben und ist in der Regel „..“ für ein Dockerfile in einem Projektordner und für die Projektmappendatei im übergeordneten Ordner. Bei .NET Framework-Projekten ist der Buildkontext der Projektordner und nicht der Projektmappenordner.

docker build -f Dockerfile ..

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.

Volumezuordnung

Damit das Debuggen in Containern funktioniert, verwendet Visual Studio die Volumezuordnung, um den Debugger und die NuGet-Ordner vom Hostcomputer zuzuordnen. Die Volumezuordnung ist in der Dokumentation zu Docker beschrieben. Sie können die Volumezuordnungen für einen Container anzeigen, indem Sie das Fenster Container in Visual Studio verwenden.

Hier sind die Volumes, die in Ihrem Container bereitgestellt werden:

Lautstärke Beschreibung
App-Ordner Enthält den Projektordner, in dem sich die Dockerfile befindet.
Ordner mit NuGet-Paketen Enthalten die NuGet-Pakete und Fallbackordner, die aus der Datei obj{project}.csproj.nuget.g.reps in das Projekt eingelesen werden.
Remotedebugger Enthält die Bits, die abhängig vom Projekttyp erforderlich sind, um den Debugger im Container auszuführen. Weitere Informationen finden Sie im Abschnitt Debuggen.
Quellordner Enthält den Buildkontext, der an Docker-Befehle übergeben wird.

Hier sind die Volumes, die in Ihrem Container bereitgestellt werden. Was in Ihren Containern angezeigt wird, hängt möglicherweise von der Nebenversion von Visual Studio 2022, die Sie verwenden, ab.

Lautstärke Beschreibung
App-Ordner Enthält den Projektordner, in dem sich die Dockerfile befindet.
HotReloadAgent Enthält die Dateien für den Hot Reload-Agent.
HotReloadProxy Enthält die zum Ausführen eines Diensts erforderlichen Dateien, mit denen der Hot Reload-Agent mit Visual Studio auf dem Host kommunizieren kann.
Ordner mit NuGet-Paketen Enthalten die NuGet-Pakete und Fallbackordner, die aus der Datei obj{project}.csproj.nuget.g.reps in das Projekt eingelesen werden.
Remotedebugger Enthält die Bits, die abhängig vom Projekttyp erforderlich sind, um den Debugger im Container auszuführen. Dies wird im Abschnitt Debuggen ausführlicher erläutert.
Quellordner Enthält den Buildkontext, der an Docker-Befehle übergeben wird.
TokenService.Proxy Enthält die Dateien, die zum Ausführen eines Diensts erforderlich sind, mit dem VisualStudioCredential mit Visual Studio auf dem Host kommunizieren kann.

Bei .NET 8 können auch zusätzliche Einhängepunkte bei Root und für den App-Benutzer vorhanden sein, die Benutzergeheimnisse und das HTTPS-Zertifikat enthalten. Und in der Visual Studio 17.10-Vorschau sind das Hot-Reload- und das Token-Service-Volume zusammen mit einer weiteren Komponente, dem Distroless Helper, unter einem einzigen Einhängepunkt, /VSTools, zusammengefasst.

Hinweis

Visual Studio 17.10 Vorschau Wenn Sie im Windows-Subsystem für Linux (WSL) die Docker-Engine ohne Docker Desktop verwenden, legen Sie die Umgebungsvariable VSCT_WslDaemon=1 so fest, dass Visual Studio beim Erstellen von Volumeneinbindungen WSL-Pfade verwendet. The NuGet package Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.20.0-Vorschau 1 ist ebenfalls erforderlich.

Für ASP.NET Core-Web-Apps kann es zwei zusätzliche Ordner für das SSL-Zertifikat und die Benutzergeheimnisse geben, was im nächsten Abschnitt näher erläutert wird.

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.

Achtung

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.

Containereinstiegspunkt

Visual Studio verwendet einen benutzerdefinierten Containereinstiegspunkt abhängig vom Projekttyp und Containerbetriebssystem. Es folgen die verschiedenen Kombinationen:

Containertyp Einstiegspunkt
Linux-Container Der Einstiegspunkt ist tail -f /dev/null. Dabei handelt es sich um eine unbegrenzte Wartezeit, um den Container aktiv zu halten. Wenn die App über den Debugger gestartet wird, ist der Debugger für die Ausführung der App verantwortlich (d. h. dotnet webapp.dll). Bei Starten ohne Debuggen führt das Tool docker exec -i {containerId} dotnet webapp.dll aus, um die App auszuführen.
Windows-Container Der Einstiegspunkt ist so etwas wie C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus, womit der Debugger so ausgeführt wird, dass er auf Verbindungen lauscht. Diese Methode gilt, wenn der Debugger die App ausführt. Beim Starten ohne Debuggen wird ein docker exec-Befehl verwendet. Bei .NET Framework-Web-Apps ist der Einstiegspunkt etwas anders, da ServiceMonitor zum Befehl hinzugefügt wird.

Der Containereinstiegspunkt kann nur in Docker-Compose-Projekten, nicht in Einzelcontainerprojekten geändert werden.

SSL-fähige ASP.NET Core-Apps

Containertools in Visual Studio unterstützen das Debuggen einer SSL-fähigen ASP.NET Core-App mit einem Entwicklungszertifikat, so wie Sie es auch ohne Container erwarten würden. Um dies zu erreichen, fügt Visual Studio einige weitere Schritte hinzu, um das Zertifikat zu exportieren und dem Container zur Verfügung zu stellen. Visual Studio erledigt beim Debuggen im Container Folgendes für Sie:

  1. Stellt mit dem Tool dev-certs sicher, dass das lokale Entwicklungszertifikat auf dem Hostcomputer vorhanden und vertrauenswürdig ist

  2. Exportiert das Zertifikat nach %APPDATA%\ASP.NET\Https und versieht es mit einem sicheren Kennwort, das im Speicher für Benutzergeheimnisse dieser bestimmten App gespeichert ist

  3. Stellt die folgenden Verzeichnisse als Volumes bereit:

    • %APPDATA%\Microsoft\UserSecrets
    • %APPDATA%\ASP.NET\Https

ASP.NET Core sucht nach einem Zertifikat, das dem Assemblynamen im Ordner Https entspricht, weshalb es dem Container in diesem Pfad zugeordnet wird. Pfad und Kennwort des Zertifikats können alternativ über Umgebungsvariablen (d. h. ASPNETCORE_Kestrel__Certificates__Default__Path und ASPNETCORE_Kestrel__Certificates__Default__Password) oder in der JSON-Datei mit Benutzergeheimnissen definiert werden. Beispiel:

{
  "Kestrel": {
    "Certificates": {
      "Default": {
        "Path": "c:\\app\\mycert.pfx",
        "Password": "strongpassword"
      }
    }
  }
}

Wenn Ihre Konfiguration sowohl containerisierte als auch nicht in Containern enthaltene Builds unterstützt, sollten Sie die Umgebungsvariablen verwenden, da die Pfade spezifisch für die Container Umgebung sind.

Weitere Informationen zur Verwendung von SSL mit ASP.NET Core-Apps in Containern finden Sie unter Hosten von ASP.NET Core-Images mit Docker über HTTPS.

Ein Codebeispiel, das das Erstellen von benutzerdefinierten Zertifikaten für eine App mit mehreren Diensten veranschaulicht, die auf dem Host und in den Containern für die HTTPS-Dienst-zu-Dienst-Kommunikation als vertrauenswürdig eingestuft sind, finden Sie unter CertExample.

Zugehöriger Inhalt