Personalizar contêineres do Docker no Visual Studio

Você pode personalizar suas imagens de contêiner editando o Dockerfile gerado pelo Visual Studio ao adicionar suporte do Docker ao seu projeto. Se você estiver criando um contêiner personalizado no 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 conteinerizados que não são óbvios no Dockerfile.

Suponha que você queira fazer uma alteração no Dockerfile e ver os resultados contêineres de depuração e produção. Nesse caso, você pode adicionar comandos no Dockerfile para modificar a primeira fase (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 durante a depuração, mas não na produção, deve criar outra fase e usar a configuração de build DockerfileFastModeStage para dizer ao Visual Studio para usar essa fase para builds 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.

Builds do Dockerfile no Visual Studio

Build de várias fases

Quando o Visual Studio compila 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. No entanto, para um projeto conteinerizado, o processo de build leva em conta as instruções do Dockerfile para criar o aplicativo conteinerizado. O Dockerfile que o Visual Studio usa é dividido em várias fases. Esse processo depende do recurso de build de várias fases do Docker.

O recurso de build de várias fases ajuda a tornar o processo de criação de contêineres mais eficiente e torna os contêineres menores, permitindo que contenham apenas os bits de que seu aplicativo precisa no tempo de execução. O build de várias fases é usado para projetos do .NET Core, e 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. A primeira fase é chamada de 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:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

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

A próxima fase é build, que aparece da seguinte maneira:

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim 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 a fase build começa a partir de uma imagem original diferente do registro (sdk em vez de aspnet), em vez 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 em um Dockerfile típico criado pelo Visual Studio:

Aquecimento do projeto

O aquecimento do projeto se refere a uma série de etapas que ocorrem quando o perfil do Docker é selecionado para um projeto (ou seja, quando um projeto é carregado ou o suporte do Docker é adicionado) para melhorar o desempenho das execuções subsequentes (F5 ou Ctrl+F5). Isso pode ser configurado 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 que o projeto.
• Extraia as imagens na primeira fase do Dockerfile (a fase base na maioria dos Dockerfiles).
• Compile 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 qualquer alteração no aplicativo não invalida o contêiner. Portanto, isso melhora significativamente o desempenho de depuração e diminui o tempo de espera para tarefas de execução prolongada, como efetuar pull 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, é MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, que, em seguida, registra em %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.

Próximas etapas

Saiba 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 durante a depuração. Consulte Configurar imagens de contêiner para depuração.

Conteúdo relacionado

• Propriedades do MSBuild para projetos de contêiner.
• Dockerfile no Windows
• Contêineres Linux no Windows