Dostosowywanie kontenerów platformy Docker w programie Visual Studio

Obrazy kontenerów można dostosować, edytując plik Dockerfile generowany przez program Visual Studio podczas dodawania obsługi platformy Docker do projektu. Niezależnie od tego, czy tworzysz dostosowany kontener z poziomu środowiska IDE programu Visual Studio, czy konfigurujesz kompilację wiersza polecenia, musisz wiedzieć, jak program Visual Studio używa pliku Dockerfile do kompilowania projektów. Musisz znać takie szczegóły, ponieważ ze względów wydajności program Visual Studio wykonuje specjalny proces tworzenia i uruchamiania konteneryzowanych aplikacji, które nie są oczywiste w pliku Dockerfile.

Załóżmy, że chcesz wprowadzić zmianę w pliku Dockerfile i zobaczyć wyniki debugowania i kontenerów produkcyjnych. W takim przypadku możesz dodać polecenia w pliku Dockerfile, aby zmodyfikować pierwszy etap (zazwyczaj base). Zobacz Modyfikowanie obrazu kontenera na potrzeby debugowania i produkcji. Jeśli jednak chcesz wprowadzić zmianę tylko podczas debugowania, ale nie w środowisku produkcyjnym, należy utworzyć kolejny etap i użyć DockerfileFastModeStage ustawienia kompilacji, aby poinformować program Visual Studio o użyciu tego etapu na potrzeby kompilacji debugowania. Zobacz Modyfikowanie obrazu kontenera tylko do debugowania.

W tym artykule opisano szczegółowo proces kompilacji programu Visual Studio dla aplikacji konteneryzowanych, a następnie zawiera informacje na temat modyfikowania pliku Dockerfile w celu wpływu zarówno na kompilacje debugowania, jak i produkcyjne, lub tylko na potrzeby debugowania.

Kompilacje pliku Dockerfile w programie Visual Studio

Uwaga

W tej sekcji opisano proces kompilacji kontenera używany przez program Visual Studio podczas wybierania typu kompilacji kontenera Dockerfile. Jeśli używasz typu kompilacji zestawu .NET SDK, opcje dostosowywania są inne, a informacje w tej sekcji nie mają zastosowania. Zamiast tego zobacz Containerize a .NET app with dotnet publish (Konteneryzowanie aplikacji .NET za pomocą polecenia dotnet publish ) i użyj właściwości opisanych w temacie Dostosowywanie kontenera w celu skonfigurowania procesu kompilacji kontenera .

Kompilacja wieloestowa

Gdy program Visual Studio skompiluje projekt, który nie używa kontenerów platformy Docker, wywołuje program MSBuild na komputerze lokalnym i generuje pliki wyjściowe w folderze (zazwyczaj bin) w folderze rozwiązania lokalnego. W przypadku projektu konteneryzowanego proces kompilacji uwzględnia jednak instrukcje pliku Dockerfile dotyczące kompilowania konteneryzowanej aplikacji. Plik Dockerfile używany przez program Visual Studio jest podzielony na wiele etapów. Ten proces opiera się na funkcji kompilacji wieloeeżowej platformy Docker.

Funkcja kompilacji wieloemetrowej pomaga zwiększyć wydajność procesu tworzenia kontenerów i zmniejsza kontenery, umożliwiając im zawieranie tylko bitów potrzebnych przez aplikację w czasie wykonywania. Kompilacja wieloestowa jest używana w projektach platformy .NET Core, a nie w projektach programu .NET Framework.

Kompilacja wieloetapowa umożliwia tworzenie obrazów kontenerów na etapach tworzących obrazy pośrednie. Rozważmy na przykład typowy plik Dockerfile. Pierwszy etap jest wywoływany base w pliku Dockerfile generowanym przez program Visual Studio, chociaż narzędzia nie wymagają tej nazwy.

FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

Wiersze w pliku Dockerfile zaczynają się od obrazu ASP.NET z usługi Microsoft Container Registry (mcr.microsoft.com) i tworzą obraz base pośredni, który uwidacznia porty 80 i 443, a następnie ustawia katalog roboczy na /appwartość .

Następnym etapem jest build, który pojawia się w następujący sposób:

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

Widać, że build etap zaczyna się od innego oryginalnego obrazu z rejestru (sdk zamiast ), a nie aspnetod podstawy. Obraz sdk zawiera wszystkie narzędzia kompilacji i z tego powodu jest o wiele większy niż obraz aspnet, który zawiera tylko składniki środowiska uruchomieniowego. Przyczyna użycia oddzielnego obrazu staje się jasna, gdy przyjrzysz się pozostałej części pliku Dockerfile:

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

Ostatni etap rozpoczyna się ponownie z baseelementu i zawiera element COPY --from=publish , aby skopiować opublikowane dane wyjściowe do końcowego obrazu. Ten proces umożliwia dużo mniejszy obraz końcowy, ponieważ nie musi zawierać wszystkich narzędzi kompilacji, które znajdowały się na obrazie sdk .

MSBuild

Uwaga

W tej sekcji opisano sposób dostosowywania kontenerów platformy Docker podczas wybierania typu kompilacji kontenera Dockerfile. Jeśli używasz typu kompilacji zestawu .NET SDK, opcje dostosowywania są inne, a informacje zawarte w tym artykule nie mają zastosowania. Zamiast tego zobacz Containerize a .NET app with dotnet publish (Konteneryzowanie aplikacji .NET za pomocą polecenia dotnet publish).

Pliki Dockerfile utworzone przez program Visual Studio dla projektów .NET Framework (i dla projektów platformy .NET Core utworzonych z wersjami programu Visual Studio przed programem Visual Studio 2017 Update 4) nie są wieloestowymi plikami Dockerfile. Kroki opisane w tych plikach Dockerfile nie kompilują kodu. Zamiast tego, gdy program Visual Studio kompiluje plik Dockerfile programu .NET Framework, najpierw kompiluje projekt przy użyciu programu MSBuild. Po pomyślnym zakończeniu program Visual Studio skompiluje plik Dockerfile, który po prostu kopiuje dane wyjściowe kompilacji z programu MSBuild do wynikowego obrazu platformy Docker. Ponieważ kroki kompilowania kodu nie są uwzględnione w pliku Dockerfile, nie można skompilować plików Dockerfile programu .NET Framework przy użyciu wiersza docker build polecenia. Należy użyć programu MSBuild do skompilowania tych projektów.

Aby utworzyć obraz dla pojedynczego projektu kontenera platformy Docker, możesz użyć programu MSBuild z opcją /t:ContainerBuild polecenia. To polecenie nakazuje programowi MSBuild skompilowanie obiektu docelowego ContainerBuild , a nie domyślnego elementu docelowego Build. Na przykład:

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

Zobaczysz dane wyjściowe podobne do tych, które są widoczne w oknie Dane wyjściowe podczas kompilowania rozwiązania z poziomu środowiska IDE programu Visual Studio. Zawsze używaj elementu /p:Configuration=Release, ponieważ w przypadkach, gdy program Visual Studio korzysta z optymalizacji kompilacji wieloeeżowej, wyniki podczas kompilowania konfiguracji debugowania mogą nie być zgodnie z oczekiwaniami. Zobacz Debugowanie.

Jeśli używasz projektu Docker Compose, użyj tego polecenia, aby skompilować obrazy:

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

Debugowanie

Uwaga

W tej sekcji opisano sposób dostosowywania kontenerów platformy Docker podczas wybierania typu kompilacji kontenera Dockerfile. Jeśli używasz typu kompilacji zestawu .NET SDK, opcje dostosowywania są inne, a większość informacji w tej sekcji nie ma zastosowania. Zamiast tego zobacz Containerize a .NET app with dotnet publish (Konteneryzowanie aplikacji .NET za pomocą polecenia dotnet publish).

Podczas kompilowania w konfiguracji debugowania istnieje kilka optymalizacji, które program Visual Studio wykonuje, co ułatwia wydajność procesu kompilacji dla projektów konteneryzowanych. Proces kompilowania aplikacji konteneryzowanych nie jest tak prosty, jak po prostu wykonanie kroków opisanych w pliku Dockerfile. Kompilowanie w kontenerze jest wolniejsze niż kompilowanie na komputerze lokalnym. Dlatego podczas kompilowania w konfiguracji debugowania program Visual Studio faktycznie kompiluje projekty na komputerze lokalnym, a następnie udostępnia folder wyjściowy kontenerowi przy użyciu instalowania woluminu. Kompilacja z włączoną optymalizacją jest nazywana kompilacją trybu szybkiego .

W trybie Szybkim program Visual Studio wywołuje docker build argument z argumentem, który informuje platformę Docker o utworzeniu tylko pierwszego etapu w pliku Dockerfile (zwykle etap).base Można to zmienić, ustawiając właściwość MSBuild, DockerfileFastModeStage, opisaną w temacie Container Tools MSBuild properties (Właściwości msBuild narzędzi kontenera). Program Visual Studio obsługuje resztę procesu bez względu na zawartość pliku Dockerfile. Dlatego podczas modyfikowania pliku Dockerfile, takiego jak dostosowanie środowiska kontenera lub zainstalowanie dodatkowych zależności, należy wprowadzić zmiany w pierwszym etapie. Wszystkie niestandardowe kroki umieszczone w etapach , publishlub final pliku Dockerfile buildnie są wykonywane.

Ta optymalizacja wydajności odbywa się tylko w przypadku kompilacji w konfiguracji debugowania . W konfiguracji wydania kompilacja jest wykonywana w kontenerze, jak określono w pliku Dockerfile.

Jeśli chcesz wyłączyć optymalizację wydajności i skompilować jako określony plik Dockerfile, ustaw właściwość ContainerDevelopmentMode na Regular w pliku projektu w następujący sposób:

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

Aby przywrócić optymalizację wydajności, usuń właściwość z pliku projektu.

Po rozpoczęciu debugowania (F5) wcześniej uruchomiony kontener jest ponownie używany, jeśli to możliwe. Jeśli nie chcesz ponownie używać poprzedniego kontenera, możesz użyć poleceń Rebuild or Clean w programie Visual Studio, aby wymusić używanie nowego kontenera w programie Visual Studio.

Proces uruchamiania debugera zależy od typu projektu i systemu operacyjnego kontenera:

Scenariusz	Proces debugera
Aplikacje platformy .NET Core (kontenery systemu Linux)	Program Visual Studio pobiera i mapuje vsdbg go do kontenera, a następnie jest wywoływany z programem i argumentami (tj dotnet webapp.dll. ), a następnie debuger dołącza do procesu.
Aplikacje platformy .NET Core (kontenery systemu Windows)	Program Visual Studio używa onecoremsvsmon kontenera i mapuje go na kontener, uruchamia go jako punkt wejścia, a następnie program Visual Studio łączy się z nim i dołącza do programu. Jest to podobne do tego, jak zwykle można skonfigurować zdalne debugowanie na innym komputerze lub maszynie wirtualnej.
Aplikacje .NET Framework	Program Visual Studio używa msvsmon kontenera i mapuje go na kontener, uruchamia go jako część punktu wejścia, w którym program Visual Studio może się z nim połączyć i dołącza do programu.

Aby uzyskać informacje na vsdbg.exetemat programu , zobacz Debugowanie offroad platformy .NET Core w systemach Linux i OS X z programu Visual Studio.

Modyfikowanie obrazu kontenera na potrzeby debugowania i produkcji

Aby zmodyfikować obraz kontenera na potrzeby debugowania i produkcji, zmodyfikuj base etap. Dodaj dostosowania do pliku Dockerfile w sekcji podstawowego etapu, zazwyczaj pierwszą sekcję w pliku Dockerfile. Zapoznaj się z dokumentacją pliku Dockerfile w dokumentacji platformy Docker, aby uzyskać informacje o poleceniach dockerfile.

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

Modyfikowanie obrazu kontenera tylko do debugowania

Ten scenariusz ma zastosowanie, gdy chcesz coś zrobić z kontenerami, aby ułatwić proces debugowania, na przykład zainstalowanie czegoś do celów diagnostycznych, ale nie chcesz, aby zainstalowano je w kompilacjach produkcyjnych.

Aby zmodyfikować kontener tylko do debugowania, utwórz etap, a następnie użyj właściwości DockerfileFastModeStage MSBuild, aby poinformować program Visual Studio o użyciu dostosowanego etapu podczas debugowania. Zapoznaj się z dokumentacją pliku Dockerfile w dokumentacji platformy Docker, aby uzyskać informacje o poleceniach dockerfile.

W poniższym przykładzie instalujemy pakiet procps-ng, ale tylko w trybie debugowania. Ten pakiet dostarcza polecenie pidof, którego program Visual Studio wymaga, ale nie znajduje się w obrazie Mariner używanym tutaj. Etap używany do debugowania w trybie szybkim to debug, niestandardowy etap zdefiniowany tutaj. Etap trybu szybkiego nie musi dziedziczyć z etapu build lub publish , ponieważ program Visual Studio instaluje wolumin, który zawiera wszystkie elementy potrzebne do uruchomienia aplikacji, zgodnie z opisem we wcześniejszej base sekcji tego artykułu.

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

W pliku projektu dodaj to ustawienie, aby poinformować program Visual Studio o użyciu niestandardowego etapu debug podczas debugowania.

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

W następnych sekcjach znajdują się informacje, które mogą być przydatne w niektórych przypadkach, na przykład gdy chcesz określić inny punkt wejścia lub jeśli aplikacja jest włączona przez protokół SSL i zmieniasz coś, co może mieć wpływ na sposób obsługi certyfikatów SSL.

Kompilowanie z wiersza polecenia

Jeśli chcesz skompilować projekt kontenera przy użyciu pliku Dockerfile poza programem Visual Studio, możesz użyć polecenia docker build, MSBuild, dotnet buildlub dotnet publish do skompilowania z poziomu wiersza polecenia.

Jeśli używasz typu kompilacji zestawu .NET SDK, nie masz pliku Dockerfile, więc nie możesz użyć polecenia docker build, zamiast tego użyj polecenia MSBuilddotnet build lub dotnet publish do skompilowania w wierszu polecenia.

Korzystanie z kompilacji platformy Docker

Aby utworzyć rozwiązanie konteneryzowane z poziomu wiersza polecenia, zazwyczaj można użyć polecenia docker build <context> dla każdego projektu w rozwiązaniu. Należy podać argument kontekstu kompilacji. Kontekst kompilacji pliku Dockerfile to folder na komputerze lokalnym, który jest używany jako folder roboczy do wygenerowania obrazu. Na przykład jest to folder, z którego kopiujesz pliki podczas kopiowania do kontenera. W projektach platformy .NET Core użyj folderu zawierającego plik rozwiązania (.sln). Wyrażona jako ścieżka względna ten argument jest zazwyczaj "."." dla pliku Dockerfile w folderze projektu i pliku rozwiązania w folderze nadrzędnym. W przypadku projektów .NET Framework kontekst kompilacji jest folderem projektu, a nie folderem rozwiązania.

docker build -f Dockerfile ..

Rozgrzewka projektu

Rozgrzewka projektu odnosi się do serii kroków, które mają miejsce po wybraniu profilu platformy Docker dla projektu (czyli po załadowaniu projektu lub dodaniu obsługi platformy Docker) w celu zwiększenia wydajności kolejnych przebiegów (F5 lub Ctrl+F5). To zachowanie można skonfigurować w obszarze Narzędzia Opcje>narzędzia Narzędzia.> Poniżej przedstawiono zadania uruchamiane w tle:

• Sprawdź, czy program Docker Desktop jest zainstalowany i uruchomiony.
• Upewnij się, że program Docker Desktop jest ustawiony na ten sam system operacyjny co projekt.
• Ściąganie obrazów na pierwszym etapie pliku Dockerfile ( base etap w większości plików Dockerfile).
• Skompiluj plik Dockerfile i uruchom kontener.

Rozgrzewka odbywa się tylko w trybie szybkim , więc uruchomiony kontener ma zainstalowany wolumin folderu aplikacji . Oznacza to, że wszelkie zmiany w aplikacji nie unieważniają kontenera. To zachowanie znacznie poprawia wydajność debugowania i zmniejsza czas oczekiwania na długotrwałe zadania, takie jak ściąganie dużych obrazów.

Mapowanie woluminów

Do debugowania w celu pracy w kontenerach program Visual Studio używa mapowania woluminów do mapowania folderów debugera i NuGet z maszyny hosta. Mapowanie woluminów zostało opisane w dokumentacji platformy Docker tutaj. Mapowania woluminów dla kontenera można wyświetlić przy użyciu okna Kontenery w programie Visual Studio.

Oto woluminy zainstalowane w kontenerze. Elementy widoczne w kontenerach mogą się różnić w zależności od używanej wersji pomocniczej programu Visual Studio 2022.

Objętość	opis
Folder aplikacji	Zawiera folder projektu, w którym znajduje się plik Dockerfile.
HotReloadAgent	Zawiera pliki agenta ponownego ładowania na gorąco.
HotReloadProxy	Zawiera pliki wymagane do uruchomienia usługi, która umożliwia agentowi ponownego ładowania hosta komunikowanie się z programem Visual Studio na hoście.
Foldery pakietów NuGet	Zawiera pakiety NuGet i foldery rezerwowe odczytywane z pliku obj{project}.csproj.nuget.g.props w projekcie.
Debuger zdalny	Zawiera bity wymagane do uruchomienia debugera w kontenerze w zależności od typu projektu. Bardziej szczegółowo wyjaśniono to w sekcji Debugowanie .
Folder źródłowy	Zawiera kontekst kompilacji przekazywany do poleceń platformy Docker.
TokenService.Proxy	Zawiera pliki wymagane do uruchomienia usługi, dzięki którym program VisualStudioCredential może komunikować się z programem Visual Studio na hoście.

W przypadku platformy .NET 8 dodatkowe punkty instalacji w katalogu głównym i dla użytkownika aplikacji zawierającego wpisy tajne użytkownika i certyfikat HTTPS również mogą być obecne. Natomiast w programie Visual Studio 17.10 (wersja zapoznawcza) wolumin usługi Przeładowywanie na gorąco i tokenu wraz z innym składnikiem pomocnika bez dystrybucji są łączone w ramach pojedynczego punktu /VSToolsinstalacji.

Uwaga

Program Visual Studio 17.10 (wersja zapoznawcza) Jeśli używasz aparatu platformy Docker w programie Podsystem Windows dla systemu Linux (WSL) bez platformy Docker Desktop, ustaw zmienną środowiskowąVSCT_WslDaemon=1, aby program Visual Studio używał ścieżek WSL podczas tworzenia instalacji woluminów. Wymagany jest również pakiet NuGet Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.20.0-Preview 1 .

W przypadku ASP.NET podstawowych aplikacji internetowych mogą istnieć dwa dodatkowe foldery dla certyfikatu SSL i wpisy tajne użytkownika, co zostało wyjaśnione bardziej szczegółowo w następnej sekcji.

Włączanie szczegółowych dzienników narzędzi kontenera

W celach diagnostycznych można włączyć niektóre dzienniki narzędzi kontenerów. Te dzienniki można włączyć, ustawiając określone zmienne środowiskowe. W przypadku projektów pojedynczego kontenera zmienna środowiskowa to MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, która następnie loguje się w %tmp%\Microsoft.VisualStudio.Containers.Toolspliku . W przypadku projektów narzędzia Docker Compose jest MS_VS_DOCKER_TOOLS_LOGGING_ENABLEDto , który następnie loguje się w %tmp%\Microsoft.VisualStudio.DockerCompose.Toolspliku .

Uwaga

Po włączeniu rejestrowania i używaniu serwera proxy tokenu na potrzeby uwierzytelniania platformy Azure poświadczenia uwierzytelniania mogą być rejestrowane jako zwykły tekst. Zobacz Konfigurowanie uwierzytelniania platformy Azure.

Punkt wejścia kontenera

Program Visual Studio używa niestandardowego punktu wejścia kontenera w zależności od typu projektu i systemu operacyjnego kontenera, oto różne kombinacje:

Typ kontenera	Punkt wejścia
Kontenery systemu Linux	Punkt wejścia to tail -f /dev/null, co jest nieskończonym oczekiwaniem, aby zachować działanie kontenera. Po uruchomieniu aplikacji za pośrednictwem debugera jest to debuger odpowiedzialny za uruchomienie aplikacji (czyli dotnet webapp.dll). Jeśli zostanie uruchomiona bez debugowania, narzędzie uruchamia element , docker exec -i {containerId} dotnet webapp.dll aby uruchomić aplikację.
Kontenery systemu Windows	Punkt wejścia jest podobny C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus do tego, który uruchamia debuger, więc nasłuchuje połączeń. Ta metoda ma zastosowanie, gdy debuger uruchamia aplikację. Po uruchomieniu bez debugowania docker exec jest używane polecenie. W przypadku aplikacji internetowych .NET Framework punkt wejścia jest nieco inny, gdzie ServiceMonitor jest dodawany do polecenia.

Punkt wejścia kontenera można modyfikować tylko w projektach narzędzia Docker Compose, a nie w projektach pojedynczego kontenera.

Aplikacje ASP.NET Core z obsługą protokołu SSL

Narzędzia kontenera w programie Visual Studio obsługują debugowanie aplikacji podstawowej z obsługą protokołu SSL ASP.NET z certyfikatem deweloperskim, tak samo jak w przypadku oczekiwania, że będzie działać bez kontenerów. Aby to zrobić, program Visual Studio dodaje kilka dodatkowych kroków w celu wyeksportowania certyfikatu i udostępnienia go kontenerowi. Oto przepływ obsługiwany przez program Visual Studio podczas debugowania w kontenerze:

1. Zapewnia obecność lokalnego certyfikatu programistycznego i zaufanego na maszynie hosta za pomocą dev-certs narzędzia.

2. Eksportuje certyfikat z %APPDATA%\ASP.NET\Https bezpiecznym hasłem przechowywanym w magazynie wpisów tajnych użytkownika dla tej konkretnej aplikacji.

3. Wolumin instaluje następujące katalogi:

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

ASP.NET Core szuka certyfikatu zgodnego z nazwą zestawu w folderze Https , dlatego jest mapowany na kontener w tej ścieżce. Alternatywnie można zdefiniować ścieżkę certyfikatu i hasło przy użyciu zmiennych środowiskowych (czyli ASPNETCORE_Kestrel__Certificates__Default__PathASPNETCORE_Kestrel__Certificates__Default__Password) lub w pliku json wpisów tajnych użytkownika, na przykład:

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

Jeśli konfiguracja obsługuje zarówno konteneryzowane, jak i niekontenerowane kompilacje, należy użyć zmiennych środowiskowych, ponieważ ścieżki są specyficzne dla środowiska kontenera.

Aby uzyskać więcej informacji na temat używania protokołu SSL z aplikacjami ASP.NET Core w kontenerach, zobacz Hosting ASP.NET Core images with Docker over HTTPS (Hostowanie obrazów ASP.NET Core za pomocą platformy Docker za pośrednictwem protokołu HTTPS).

Przykładowy kod przedstawiający tworzenie certyfikatów niestandardowych dla aplikacji wielousługowej, która jest zaufana na hoście i w kontenerach dla komunikacji między usługami HTTPS, zobacz CertExample.

Powiązana zawartość

• Właściwości programu MSBuild dla projektów kontenerów.
• MSBuild
• Plik Dockerfile w systemie Windows
• Kontenery systemu Linux w systemie Windows