Neste post vou falar um pouco sobre como criar imagens docker otimizadas para nossas aplicações através do multi-stage build.
Em muitos projetos notamos a presença de arquivos como Dockerfile.build, Dockerfile.tests e etc., arquivos estes que, representam etapas em processos de build e que são difíceis de criar e manter pelo time.
A partir da versão 17.05 do Docker, lançada a 1 ano atrás, o time de desenvolvimento disponibilizou suporte a multi-stage build, basicamente, são extensões dos comandos FROM e COPY que nos permite criar um Dockerfile com múltiplas fases de build, ou steps.
Para este post irei utilizar como exemplo uma aplicação ASP.NET Core 2, onde o processo de build da imagem irá conter múltiplas fases, como restore, testes, publicação e etc. Nossa imagem final irá conter apenas o ambiente mínimo necessário para rodar a aplicação e o pacote do projeto, sem dependências não produtivas, o que tornará a imagem final mais leve.
Você pode baixar todos os arquivos do projeto no github e pular para a parte do Dockerfile, mas se desejar, vamos criar juntos o projeto web e os testes.
Projeto Web
Iremos utilizar uma aplicação web convencional, criando através do cli.
Estou utilizando Ubuntu 16 para criar este post, mas você pode utilizar o SO de sua preferência.
Estou assumindo que você já possua o dotnet sdk e o docker instalados 😉
No seu terminal, crie uma aplicação web e certifique-se de que ela esteja abrindo no navegador.
mkdir aspnetproject && cd aspnetproject mkdir web dotnet new sln dotnet new web -o web dotnet sln add web/web.csproj && dotnet restore cd web && dotnet run Hosting environment: Production Content root path: /home/lazaro/aspnetproject/web Now listening on: http://localhost:5000 Application started. Press Ctrl+C to shut down.
Com isso já temos nossa aplicação web disponível em http://localhost:5000/.
Projeto de Testes
Iremos criar um projeto de teste para que possamos usar como exemplo.
cd .. && mkdir tests && dotnet new mstest -o tests dotnet sln add tests/tests.csproj dotnet test tests/tests.csproj Build started, please wait... Build completed. Test run for /home/lazaro/aspnetproject/tests/bin/Debug/netcoreapp2.0/tests.dll(.NETCoreApp,Version=v2.0) Microsoft (R) Test Execution Command Line Tool Version 15.3.0-preview-20170628-02 Copyright (c) Microsoft Corporation. All rights reserved. Starting test execution, please wait... Total tests: 1. Passed: 1. Failed: 0. Skipped: 0. Test Run Successful. Test execution time: 1.3408 Seconds
Agora que temos nossa aplicação e nossos testes, vamos colocar tudo isso dentro de uma imagem.
Dockerfile e as mudanças no FROM e no COPY
Antes de criamos nosso Dockerfile vamos entender quais melhorias ocorreram no FROM e no COPY.
Anteriormente, tinhamos apenas um comando FROM que era carregado inicialmente e estabelecia qual imagem seria utilizada, afetando todos os comandos subsequentes. Com multi-stages podemos utilizar quantos comandos FROM desejarmos.
Cada FROM é um novo estágio que substitui o anterior, é como uma nova imagem, totalmente independente e isolada. Desta forma, se no estágio inicial estivermos utilizando uma imagem com .NET Core e no último estágio estamos utilizando uma imagem sem suporte a .NET Core a imagem final gerada ficará sem este suporte.
Outra mudança no FROM ocorreu em sua assinatura, agora existe a possibilidade de nomear os estágios através da instrução as.
FROM microsoft/aspnetcore-build:1.1 as build ... ... FROM microsoft/dotnet:1.1-runtime as release ... ... ...
Neste primeiro momento podemos notar que cada etapa do build pode conter a imagem mais eficiente possível, seja uma etapa para executar um teste ou rodar a aplicação final.
Porém, nada disso faz muito sentido sem a possibilidade de utilizarmos informações das etapas anteriores, por isso, o comando COPY possui o argumento --from=<nome do estágio>, permitindo assim a copia de arquivos existentes em etapas anteriores
Exemplo:
FROM microsoft/aspnetcore-build:1.1 as build WORKDIR /publish COPY .bowerrc bower.json ./ RUN bower install COPY my-app.csproj . RUN dotnet restore COPY . . RUN dotnet publish --output ./out FROM microsoft/dotnet:1.1-runtime as release WORKDIR /dotnetapp COPY --from=build /publish/out . ENV ASPNETCORE_URLS "http://0.0.0.0:5000/" ENTRYPOINT ["dotnet", "my-app.dll"]
Criando nosso Dockerfile
Nossa aplicação possui uma pasta para o projeto web e outra para o projeto de testes, precisamos garantir que somente se os testes estiverem passando a imagem será gerada.
Com esse cenário em mente, se executarmos o teste dentro do build e ele retornar falha o processo é interrompido automaticamente.
# Restaura e copia os arquivos do projeto FROM microsoft/aspnetcore-build:2.0 AS base-env COPY . . RUN dotnet restore # Roda os testes de unidade FROM microsoft/aspnetcore-build:2.0 AS test-env WORKDIR /tests COPY --from=base-env ./tests . RUN dotnet test tests.csproj # Publica o projeto web FROM microsoft/aspnetcore-build:2.0 AS build-env WORKDIR /app COPY --from=base-env ./web . RUN dotnet publish web.csproj -c Release -o out # Copia a pasta do projeto web publicado e roda a aplicação web FROM microsoft/aspnetcore:2.0 WORKDIR /app COPY --from=build-env /app/out . ENTRYPOINT ["dotnet", "web.dll"]
Nas primeiras 3 etapas estamos utilizando a imagem oficial para o processo de build de aplicações ASP.NET Core 2.
FROM microsoft/aspnetcore-build:2.0
Esta imagem já possui alguns recursos como:
- .NET Core SDK
- NuGet com cache para pacotes comumente utilizados em projetos asp.net core
- Node.js
- Bower
- Gulp
Na primeira etapa eu copio os arquivos do projeto e faço o restore.
COPY . . RUN dotnet restore
Na segunda etapa, o qual chamei de test-env, estou setando uma pasta local como pasta padrão /tests, copiando apenas a pasta com o projeto de testes a partir do base-env e rodando os testes.
WORKDIR /tests COPY --from=base-env ./tests . RUN dotnet test tests.csproj
Note que, nesse momento o contexto da imagem anterior já não é utilizado, logo, a pasta tests precisa ser copiada para a minha nova etapa através do comando COPY com o argumento --from=base.
Crio então uma nova etapa para a realização do publish do projeto web.
FROM microsoft/aspnetcore-build:2.0 AS build-env WORKDIR /app COPY --from=base-env ./web . RUN dotnet publish web.csproj -c Release -o out
Na etapa final estou utilizando a imagem microsoft/aspnetcore:2.0, o qual é mais otimizada para executar a aplicação, não possuindo as dependências que são geralmente utilizadas para os processos de build e testes.
FROM microsoft/aspnetcore:2.0
Novamente, posso copiar a pasta com o projeto web que foi gerada em etapas anteriores e então definir o entrypoint para rodar a aplicação, mesmo que ela tenha utilizado uma imagem completamente diferente.
WORKDIR /app COPY --from=build-env /app/out . ENTRYPOINT ["dotnet", "web.dll"]
Gere a imagem e em seguida rode em um novo container liberando a porta 8080.
docker build -t aspnetapp . docker run -p 8080:80 –name myapp aspnetapp
Tamanho final da imagem
Para efeito de comparação, caso utlizasse apenas um passo, com a imagem com todas as dependências, nossa imagem final teria em torno de 2GB, já com o uso de multi-stage podemos utilizar a imagem final de runtime, o qual possui 325MB + 3MB da nossa aplicação.
Espero que tenham gostado e que aproveitem ao máximo o multi-stage para criar imagens finais mais eficientes, seja em .NET ou quaisquer outras plataformas.
(Crosspost de http://lazarofl.github.io/2018/04/17/Docker-MultiStage/)
Lazaro Fernandes Lima Suleiman
Desenvolvedor