Udostępnij przez

Dostosowywanie obrazów kontenerów na potrzeby debugowania

W tym artykule 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.

W tym artykule opisano sposób dostosowywania kontenerów 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.

Wymagania wstępne

Wymagania wstępne

  • Docker Desktop.
  • Program Visual Studio, który ma zainstalowane pakiety do tworzenia ASP.NET i aplikacji internetowych, rozwoju aplikacji na platformie Azure, i/lub rozwoju aplikacji desktopowych .NET.

Optymalizacje trybu szybkiego

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.

W trybie Szybkim program Visual Studio wywołuje docker build lub podman build z argumentem, który nakazuje środowisku uruchomieniowemu kontenera utworzenie tylko pierwszego etapu w pliku Dockerfile (zwykle etap base). Można to zmienić, ustawiając właściwość MSBuild , ContainerFastModeStagektóra zastępuje przestarzałe DockerfileFastModeStage. Zobacz 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 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) Visual Studio pobiera vsdbg i mapuje go do kontenera, a następnie jest on wywoływany z twoim programem i argumentami (czyli dotnet webapp.dll).
aplikacje .NET Core (kontenery systemu Windows) Program Visual Studio używa onecoremsvsmon, mapuje go do kontenera i uruchamia jako punkt wejścia.
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) Program Visual Studio używa onecoremsvsmon, mapuje go do kontenera i uruchamia jako punkt wejścia.
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 pierwszy etap w pliku Dockerfile, zwykle nazywany etapem base . Zapoznaj się z odnośnikiem Dockerfile w dokumentacji Docker, aby uzyskać informacje o poleceniach Dockerfile.

Wskazówka

Jeśli projekt używa właściwości MSBuild DockerfileFastModeStage, należy wybrać odpowiedni etap, aby dodać dostosowanie, które przepływa do etapu końcowego oraz DockerfileFastModeStage, jeśli to możliwe. Zobacz Właściwości kompilacji narzędzi kontenera.

Aby zmodyfikować obraz kontenera na potrzeby debugowania i produkcji, zmodyfikuj pierwszy etap w pliku Dockerfile, zwykle nazywany etapem base . Zapoznaj się z odnośnikiem Dockerfile w dokumentacji Docker, aby uzyskać informacje o poleceniach Dockerfile.

Wskazówka

Jeśli projekt używa ContainerFastModeStage (lub przestarzałego odpowiednika DockerfileFastModeStage) właściwości MSBuild, należy wybrać odpowiedni etap dostosowywania, który przepływa do końcowego etapu ContainerFastModeStage i, jeśli to możliwe. Zobacz Właściwości kompilacji narzędzi kontenera.

# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER $APP_UID
WORKDIR /app
EXPOSE 8080
EXPOSE 8081
# <add your commands here>

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:8.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 Docker, aby uzyskać informacje o poleceniach Dockerfile.

Aby zmodyfikować kontener tylko do debugowania, utwórz etap, a następnie użyj właściwości MSBuild ContainerFastModeStage, aby poinformować program Visual Studio o użyciu dostosowanego etapu podczas debugowania. Zapoznaj się z odnośnikiem Dockerfile w dokumentacji 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:8.0 AS base
USER $APP_UID
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

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:8.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>

  <PropertyGroup>
     <!-- other property settings -->
     <ContainerFastModeStage>debug</ContainerFastModeStage>
  </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.

Powiązana zawartość

  • Last updated on