Compartilhar via

Personalizar contêineres no Visual Studio

Você pode personalizar suas imagens de contêiner editando o Dockerfile gerado pelo Visual Studio ao adicionar suporte de contêiner ao seu projeto. Se você estiver criando um contêiner personalizado do IDE do Visual Studio ou configurando um build de linha de comando, precisará saber como o Visual Studio usa o Dockerfile para criar seus projetos. Você precisa saber esses detalhes porque, por motivos de desempenho, o Visual Studio segue um processo especial para criar e executar aplicativos em contêineres que não são óbvios no Dockerfile.

Suponha que você queira fazer uma alteração no Dockerfile e ver os resultados tanto nos contêineres de debug quanto nos de produção. Nesse caso, você pode adicionar comandos no Dockerfile para modificar o primeiro estágio (geralmente base). Confira Modificar a imagem de contêiner para depuração e produção. Porém, se você quiser fazer uma alteração somente ao depurar, mas não na produção, você deve criar outro estágio e usar a configuração de build ContainerFastModeStage para instruir o Visual Studio a usar aquele estágio para compilações de depuração. Confira Modificar a imagem de contêiner somente para depuração.

Suponha que você queira fazer uma alteração no Dockerfile e ver os resultados tanto nos contêineres de debug quanto nos de produção. Nesse caso, você pode adicionar comandos no Dockerfile para modificar o primeiro estágio (geralmente base). Confira Modificar a imagem de contêiner para depuração e produção. Porém, se você quiser fazer uma alteração somente ao depurar, mas não na produção, você deve criar outro estágio e usar a configuração de build DockerfileFastModeStage para instruir o Visual Studio a usar aquele estágio para compilações de depuração. Confira Modificar a imagem de contêiner somente para depuração.

Este artigo explica detalhadamente o processo de build do Visual Studio para aplicativos conteinerizados e contém informações sobre como modificar o Dockerfile para afetar os builds de depuração e produção ou apenas para depuração.

Pré-requisitos

Pré-requisitos

  • Área de Trabalho do Docker.
  • Visual Studio com o ASP.NET e desenvolvimento na Web, carga de trabalho de desenvolvimento do Azure e/ou carga de trabalho de desenvolvimento da área de trabalho do .NET instalada.

Builds do Dockerfile no Visual Studio

Nota

Esta seção descreve o processo de build de contêiner que o Visual Studio usa quando você escolhe 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 as informações nesta seção não serão aplicáveis. Em vez disso, consulte Containerize um aplicativo .NET com dotnet publish e use as propriedades descritas em Personalizar seu contêiner para configurar o processo de build do contêiner.

Build de várias fases

Quando o Visual Studio cria um projeto que não usa contêineres do Docker, ele invoca o MSBuild no computador local e gera os arquivos de saída em uma pasta (normalmente bin) na pasta da solução local. Para um projeto em contêineres, no entanto, o processo de build leva em conta as instruções do Dockerfile para a criação do aplicativo em contêineres. O Dockerfile usado pelo Visual Studio é dividido em vários estágios. Esse processo depende do recurso de build de vários estágios do Docker.

O recurso de build de vários estágios ajuda a tornar o processo de criação de contêineres mais eficiente e torna os contêineres menores, permitindo que eles contenham apenas os bits necessários ao seu aplicativo em tempo de execução.

O build de várias fases é usado para projetos do .NET Core, não para projetos do .NET Framework.

O build de várias fases permite que imagens de contêiner sejam criadas em fases que produzem imagens intermediárias. Por exemplo, considere um Dockerfile típico. O primeiro estágio é chamado base no Dockerfile gerado pelo Visual Studio, embora as ferramentas não exijam esse nome.

# 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

As linhas no Dockerfile começam com a imagem ASP.NET do Registro de Contêiner da Microsoft (mcr.microsoft.com) e criam uma imagem base intermediária que expõe as portas 8080 e 8081 e define o diretório de trabalho como /app.

Quando você estiver direcionando o .NET 7 e posterior, a linha USER $APP_UID será exibida, definindo o contêiner para ser executado sem privilégios elevados, com um nome de usuário obtido da variável de ambiente APP_UID. As portas são 8080 e 8081, em vez de 80 e 443, que exigem privilégios elevados.

O próximo estágio é build, que aparece da seguinte maneira:

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:8.0 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

Você pode ver que o estágio build começa a partir de uma imagem original diferente do registro (sdk em vez de aspnet), ao invés de continuar da base. A imagem sdk tem todas as ferramentas de build e, por esse motivo, é muito maior do que a imagem aspnet, que contém apenas componentes de runtime. O motivo para usar uma imagem separada fica claro quando você olha para o restante do Dockerfile:

# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication43.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", "WebApplication43.dll"]

A fase final começa novamente em base e inclui o COPY --from=publish para copiar a saída publicada para a imagem final. Esse processo possibilita que a imagem final seja muito menor, pois não precisa incluir todas as ferramentas de build que estavam na imagem sdk.

A tabela a seguir resume os estágios usados no Dockerfile típico criado pelo Visual Studio:

Estágio Descrição
base Cria a imagem de runtime base em que o aplicativo compilado é publicado. As configurações que precisam estar disponíveis no runtime vão para cá, como portas e variáveis de ambiente. Este estágio é utilizado ao executar o Visual Studio no modo rápido (padrão para a configuração de depuração).
build O projeto é desenvolvido nesta fase. A imagem base do SDK do .NET é usada, que tem os componentes necessários para criar seu projeto.
publicar Esse estágio deriva do estágio de build e publica seu projeto, que será copiado para o estágio final.
final Este estágio configura como iniciar o aplicativo e é usado na produção ou ao executar do Visual Studio no modo padrão (padrão ao não usar a configuração de depuração).
aotdebug Este estágio é usado como base para o estágio final ao iniciar a partir do VS para dar suporte à depuração no modo normal (padrão ao não usar a configuração de depuração).

Nota

O estágio aotdebug só tem suporte para contêineres do Linux. É utilizado no Visual Studio 2022 17.11 ou posteriores se a implantação AOT nativa estiver habilitada no projeto.

Aquecimento do projeto

O aquecimento do projeto refere-se a uma série de etapas que ocorrem quando o perfil de contêiner é selecionado para um projeto (ou seja, quando um projeto é carregado ou o suporte ao contêiner é adicionado) para melhorar o desempenho das execuções subsequentes (F5 ou Ctrl+F5).

Esse comportamento é configurável no painel FerramentasOpções emTodas as ConfiguraçõesFerramentas de Contêiner. Estas são as tarefas executadas em segundo plano:

  • Verifique se o runtime do contêiner (Docker Desktop ou Podman) está instalado e em execução.
  • Verifique se o Docker Desktop está definido como o mesmo sistema operacional do projeto. (Essa verificação não é aplicável ao Podman, que só dá suporte a contêineres do Linux.)
  • Extraia as imagens na primeira fase do Dockerfile (a fase base na maioria dos Dockerfiles).
  • Crie o Dockerfile e inicie o contêiner.

Esse comportamento é configurável em Ferramentas>Opções>Ferramentas de Contêiner. Estas são as tarefas executadas em segundo plano:

  • Verifique se o Docker Desktop está instalado e em execução.
  • Verifique se o Docker Desktop está definido como o mesmo sistema operacional do projeto.
  • Extraia as imagens na primeira fase do Dockerfile (a fase base na maioria dos Dockerfiles).
  • Crie o Dockerfile e inicie o contêiner.

O aquecimento ocorre apenas no modo Rápido, portanto, o contêiner em execução tem a pasta do aplicativo montada em volume. Isso significa que todas as alterações no aplicativo não invalidam o contêiner. Esse comportamento melhora significativamente o desempenho de depuração e diminui o tempo de espera para tarefas de execução longa, como a extração de imagens grandes.

Habilitar logs detalhados das ferramentas de contêiner

Para fins de diagnóstico, você pode habilitar determinados logs das ferramentas de contêiner. Você pode habilitar esses logs definindo determinadas variáveis de ambiente. Para projetos de contêiner único, a variável de ambiente é MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, que então faz o logon em %tmp%\Microsoft.VisualStudio.Containers.Tools. Para projetos do Docker Compose, a variável é MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, que então realiza login em %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.

Aviso

Quando o registro em log está habilitado e você está usando um proxy de token para autenticação do Azure, as credenciais de autenticação podem ser registradas como texto sem formatação. Consulte Configurar a autenticação do Azure.

Próximas etapas

Saiba mais sobre como usar os estágios do Dockerfile para personalizar as imagens usadas para depuração e produção, por exemplo, como instalar uma ferramenta na imagem somente ao depurar. Consulte Configurar imagens de contêiner para depuração.

Conteúdo relacionado

  • Last updated on