Consulte Personalizar imagens de contêiner para depuração
Observação
Esta seção descreve como você pode personalizar seus contêineres do Docker ao escolher o tipo de build de contêiner do Dockerfile. Se você estiver usando o tipo de build do SDK do .NET, as opções de personalização serão diferentes e a maioria das informações nesta seção não serão aplicáveis. Em vez disso, consulte Colocar em contêiner um aplicativo .NET com dotnet publish.
Ao compilar na configuração de Depuração, o Visual Studio faz várias otimizações que ajudam no desempenho do processo de compilação para projetos conteinerizados. O processo de compilação para aplicativos conteinerizados não é tão simples quanto apenas seguir as etapas descritas no Dockerfile. A compilação em um contêiner é muito mais lenta do que a compilação no computador local. Portanto, quando você compila na configuração de Depuração, o Visual Studio realmente compila seus projetos no computador local e compartilha a pasta de saída para o contêiner usando a montagem de volume. Um build com essa otimização habilitada é chamado de build de modo Rápido.
No modo Rápido, o Visual Studio chama docker build com um argumento que informa ao Docker para criar apenas o primeiro estágio no Dockerfile (normalmente, o estágio base). Você pode alterá-lo definindo a propriedade do MSBuild, DockerfileFastModeStage, descrita nas propriedades do MSBuild das Ferramentas de Contêiner. O Visual Studio manipula o restante do processo, sem considerar o conteúdo do Dockerfile. Portanto, ao modificar o Dockerfile, como personalizar o ambiente de contêiner ou instalar dependências adicionais, você deve colocar suas modificações na primeia fase. As etapas personalizadas colocadas as fasesbuild, publish ou final do Dockerfile não serão executadas.
Essa otimização de desempenho, normalmente só ocorre quando você cria na configuração de Depuração. Na configuração de Versão, o build ocorre no contêiner, conforme especificado no Dockerfile. Você pode habilitar esse comportamento para a configuração de versão definindo ContainerDevelopmentMode como Rápido no arquivo de projeto:
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<ContainerDevelopmentMode>Fast</ContainerDevelopmentMode>
</PropertyGroup>
Se você quiser desabilitar a otimização de desempenho para todas as configurações e criar como o Dockerfile especifica, defina a propriedade ContainerDevelopmentMode como Regular no arquivo de projeto da seguinte maneira:
<PropertyGroup>
<ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>
Para restaurar a otimização de desempenho, remova a propriedade do arquivo de projeto.
Quando você inicia a depuração (F5), um contêiner iniciado anteriormente é reutilizado, se possível. Se você não quiser reutilizar o contêiner anterior, pode usar comandos os Rebuild ou Clean no Visual Studio para forçar o Visual Studio a usar um novo contêiner.
O processo de execução do depurador depende do tipo de projeto e do sistema operacional de contêiner:
| Cenário | Processo do depurador |
|---|---|
| Aplicativos do .NET Core (contêineres do Linux) | O Visual Studio baixa vsdbg e mapeia para o contêiner. Em seguida, ele é chamado com o programa e os argumentos (ou seja, dotnet webapp.dll) e depois o depurador anexa ao processo. |
| Aplicativos do .NET Core (contêineres do Windows) | O Visual Studio o usa onecoremsvsmon e mapeia para o contêiner, executa como o ponto de entrada e, em seguida, o Visual Studio se conecta a ele e anexa ao programa. |
| Aplicativos do .NET Framework | O Visual Studio o usa msvsmon e mapeia para o contêiner, executa como o parte do ponto de entrada em que o Visual Studio pode se conectar a ele e anexa ao programa. Isso é semelhante a como você normalmente configuraria a depuração remota em outro computador ou máquina virtual. |
Para obter informações sobre vsdbg.exe, confira Offroad debugging of .NET Core on Linux and OS X from Visual Studio.
Modificar a imagem de contêiner para depuração e produção
Para modificar a imagem de contêiner para depuração e produção, modifique a fase base. Adicione suas personalizações ao Dockerfile na seção da fase base, geralmente a primeira seção no Dockerfile. Veja a referência do Dockerfile na documentação do Docker para obter informações sobre os comandos do 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"]
Modificar a imagem de contêiner somente para depuração
Você pode personalizar seus contêineres de determinadas maneiras para ajudar na depuração, como instalar algo para fins de diagnóstico, sem afetar as criações de produção.
Para modificar o contêiner somente para depuração, crie uma fase e use a propriedade do MSBuild DockerfileFastModeStage para dizer ao Visual Studio para usar a fase personalizada durante a depuração. Veja a referência do Dockerfile na documentação do Docker para obter informações sobre os comandos do Dockerfile.
Observação
As instruções aqui se aplicam à caixa de contêiner único. Você também pode fazer a mesma coisa para vários contêineres com o Docker Compose, mas as técnicas necessárias para o Docker Compose são um pouco diferentes. Por exemplo, o palco é controlado por uma configuração no arquivo dockercompose.debug.yml.
No exemplo a seguir, instalamos o pacote procps-ng, mas somente no modo de depuração. O pacote fornece o comando pidof, que o Visual Studio exige (ao usar o .NET 5 e versões anteriores), mas não está na imagem do Mariner usada aqui. A fase que usamos para depuração de modo rápido é debug, uma fase personalizada definida aqui. A fase de modo rápido não precisa herdar da fase build ou publish, ela pode herdar diretamente da fase base, pois o Visual Studio montará um volume que contém tudo o que for necessário para executar o aplicativo, conforme descrito anteriormente neste artigo.
#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"]
No arquivo de projeto, adicione essa configuração para dizer o Visual Studio para usar a fase personalizada debug durante a depuração.
<PropertyGroup>
<!-- other property settings -->
<DockerfileFastModeStage>debug</DockerfileFastModeStage>
</PropertyGroup>
Personalizar imagens de depuração com implantação AOT
Para dar suporte à implantação AOT nativa, o depurador GNU (GDB) é instalado, mas apenas na imagem usada durante a depuração, não na imagem final do tempo de execução. O Dockerfile inclui um argumento de compilação LAUNCHING_FROM_VS que pode ser true ou false. Se true, o estágio aotdebug é usado, que é onde o GDB está instalado. Observe que o Visual Studio só dá suporte a AOT e GDB nativos para contêineres do 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"]
Você pode usar aotstage no Dockerfile para personalizar a imagem usada no momento da depuração, sem afetar a imagem final usada quando não for iniciada do Visual Studio ou em produção. Por exemplo, você pode instalar uma ferramenta para uso somente durante a depuração.