Dostosowywanie obrazów kontenerów na potrzeby debugowania
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 zwykle występuje tylko w przypadku kompilacji w konfiguracji debugowania . W konfiguracji wydania kompilacja jest wykonywana w kontenerze, jak określono w pliku Dockerfile. To zachowanie konfiguracji wydania można włączyć, ustawiając wartość ContainerDevelopmentMode Fast w pliku projektu:
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<ContainerDevelopmentMode>Fast</ContainerDevelopmentMode>
</PropertyGroup>
Jeśli chcesz wyłączyć optymalizację wydajności dla wszystkich konfiguracji 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. |
| 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. Jest to podobne do tego, jak zwykle można skonfigurować zdalne debugowanie na innym komputerze lub maszynie wirtualnej. |
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.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# <add your commands here>
# This stage is used to build the service project
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
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication3.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", "WebApplication3.dll"]
Modyfikowanie obrazu kontenera tylko do debugowania
Kontenery można dostosować w określony sposób, aby ułatwić debugowanie, takie jak instalowanie czegoś do celów diagnostycznych, bez wpływu na kompilacje produkcyjne.
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.
Uwaga
Instrukcje w tym miejscu dotyczą przypadku pojedynczego kontenera. Można również wykonać te same czynności w przypadku wielu kontenerów za pomocą narzędzia Docker Compose, ale techniki wymagane dla narzędzia Docker Compose są nieco inne. Na przykład etap jest kontrolowany przez ustawienie w dockercompose.debug.yml pliku.
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 (w przypadku określania wartości docelowej dla platformy .NET 5 i starszych), ale nie znajduje się w tym miejscu. 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.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
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
# This stage is used to build the service project
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
# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication1.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", "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>
Dostosowywanie obrazów debugowania przy użyciu wdrożenia usługi AOT
Aby obsługiwać natywne wdrożenie AOT, debuger GNU (GDB) jest zainstalowany, ale tylko na obrazie używanym podczas debugowania, a nie na końcowym obrazie środowiska uruchomieniowego. Plik Dockerfile zawiera argument LAUNCHING_FROM_VS kompilacji, który może być true lub false. aotdebug Jeśli truejest używany etap, w którym jest zainstalowana baza danych GDB. Należy pamiętać, że program Visual Studio obsługuje tylko natywne kontenery AOT i GDB dla systemu Linux.
# These ARGs allow for swapping out the base used to make the final image when debugging from VS
ARG LAUNCHING_FROM_VS
# This sets the base image for final, but only if LAUNCHING_FROM_VS has been defined
ARG FINAL_BASE_IMAGE=${LAUNCHING_FROM_VS:+aotdebug}
# ... (other stages omitted)
# This stage is used as the base for the final stage when launching from VS to support debugging in regular mode (Default when not using the Debug configuration)
FROM base as aotdebug
USER root
# Install GDB to support native debugging
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
gdb
USER app
# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM ${FINAL_BASE_IMAGE:-mcr.microsoft.com/dotnet/runtime-deps:8.0} AS final
WORKDIR /app
EXPOSE 8080
COPY --from=publish /app/publish .
ENTRYPOINT ["./WebApplication1"]
Możesz użyć aotstage w pliku Dockerfile, aby dostosować obraz używany w czasie debugowania, bez wpływu na końcowy obraz używany, gdy nie jest uruchamiany z programu Visual Studio lub w środowisku produkcyjnym. Na przykład można zainstalować narzędzie do użycia tylko podczas debugowania.