Dostosowywanie obrazów kontenerów na potrzeby debugowania
Notatka
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 Konteneryzowanie aplikacji .NET za pomocą polecenia dotnet publish.
Podczas kompilowania w konfiguracji Debug jest kilka optymalizacji, które program Visual Studio wykonuje, co pomaga w poprawie wydajności 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. Podczas kompilowania w konfiguracji Debug program Visual Studio faktycznie kompiluje projekty na komputerze lokalnym, a następnie udostępnia folder wyjściowy kontenerowi przy użyciu zamontowania woluminu. Kompilacja z włączoną optymalizacją jest nazywana kompilacją trybu Fast.
W trybie Fast program Visual Studio wywołuje docker build z argumentem, który informuje platformę Docker o budowaniu tylko pierwszego etapu w pliku Dockerfile (zwykle etapie base). Można to zmienić, ustawiając właściwość MSBuild, DockerfileFastModeStage, opisane w Container Tools MSBuild properties. 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 build, publishlub final etapach pliku Dockerfile nie są wykonywane.
Ta optymalizacja wydajności zwykle występuje tylko w przypadku budowania w konfiguracji Debug. W konfiguracji wydania kompilacja jest wykonywana w kontenerze określonym w pliku Dockerfile. To zachowanie dla konfiguracji wydania można włączyć, ustawiając ContainerDevelopmentMode na 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 skorzystać z poleceń Rebuild lub Clean w programie Visual Studio, aby wymusić użycie nowego kontenera.
Proces uruchamiania debugera zależy od typu projektu i systemu operacyjnego kontenera:
| Scenariusz | Proces debuggera |
|---|---|
| aplikacje platformy .NET Core (kontenery systemu Linux) | Program Visual Studio pobiera vsdbg i mapuje go na kontener, po czym jest wywoływany z twoim programem i argumentami (czyli dotnet webapp.dll), a następnie debugger dołącza do procesu. |
| aplikacje .NET Core (kontenery systemu Windows) | Visual Studio używa onecoremsvsmon, mapuje go do kontenera, uruchamia jako punkt wejścia, a następnie Visual Studio łączy się z nim i przyłącza się do programu. |
| aplikacje .NET Framework | Program Visual Studio używa msvsmon i mapuje go do kontenera, 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 temat vsdbg.exe, zobacz niekonwencjonalne debugowanie platformy .NET Core w systemach Linux i macOS za pomocą programu Visual Studio.
Modyfikowanie obrazu kontenera na potrzeby debugowania i produkcji
Aby zmodyfikować obraz kontenera na potrzeby debugowania i produkcji, zmodyfikuj etap base. Dodaj dostosowania do pliku Dockerfile w sekcji etapu bazowego, zazwyczaj pierwsza sekcja w pliku Dockerfile. Zapoznaj się z odnośnikiem Dockerfile w dokumentacji 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 MSBuild DockerfileFastModeStage, aby poinformować program Visual Studio o użyciu dostosowanego etapu podczas debugowania. Zapoznaj się z odnośnikiem Dockerfile w dokumentacji platformy Docker, aby uzyskać informacje o poleceniach Dockerfile.
Notatka
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 pliku dockercompose.debug.yml.
W poniższym przykładzie instalujemy pakiet procps-ng, ale tylko w trybie debugowania. Ten pakiet dostarcza polecenie pidof, którego wymaga Visual Studio (przy celowaniu w .NET 5 i starsze), ale nie znajduje się w obrazie Mariner używanym tutaj. Etap używany do debugowania w trybie szybkim jest debug, niestandardowy etap zdefiniowany tutaj. Etap trybu szybkiego nie musi dziedziczyć z etapu build ani publish; może dziedziczyć bezpośrednio z etapu base, ponieważ program Visual Studio montuje wolumin, który zawiera wszystkie elementy potrzebne do uruchomienia aplikacji, zgodnie z opisem wcześniej w tym artykule.
#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 kompilacji LAUNCHING_FROM_VS, który może być true lub false. Jeśli true, używany jest etap aotdebug, w którym zainstalowano bazę 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 ostateczny 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.