Ho scritto di recente sul blog sull'ottimizzazione delle dimensioni dei file .NET e ASP.NET Docker. .NET Core 2.0 è stato precedentemente creato su un'immagine Debian, ma oggi è disponibile un'immagine di anteprima con .NET Core 2.1 nightlies che utilizzano Alpine. Puoi leggere l'annuncio qui su questa nuova immagine di anteprima di Alpine. C'è anche un buon post di rollup su .NET e Docker.
Hanno aggiunto due nuove immagini:
2.1-runtime-alpine2.1-runtime-deps-alpine
Il supporto Alpine fa parte della versione .NET Core 2.1. Le immagini .NET Core 2.1 sono attualmente fornite nel repository microsoft/dotnet-nightly, incluse le nuove immagini Alpine. Le immagini .NET Core 2.1 verranno promosse nel repository microsoft/dotnet quando verranno rilasciate nel 2018.
NOTA:l'immagine -runtime-deps- contiene le dipendenze necessarie per un'applicazione .NET Core, ma NON il runtime .NET Core stesso. Questa è l'immagine che useresti se la tua app fosse un'applicazione autonoma che includeva una copia del runtime .NET Core. Si tratta di app pubblicate con -r [runtimeid]. La maggior parte delle persone utilizzerà l'immagine -runtime- che includeva il runtime completo di .NET Core. Per essere chiari:
- Il
runtimeimage contiene il runtime .NET Core ed è destinato all'esecuzione di applicazioni distribuite dipendenti da Framework - vedere l'esempio- Il
runtime-depsl'immagine contiene solo le dipendenze native necessarie da .NET Core ed è progettata per eseguire applicazioni distribuite autonomamente - vedere l'esempio
È meglio con .NET Core usare file di build in più fasi, quindi hai un contenitore che compila la tua app e uno che contiene i risultati di quella build. In questo modo non finirai per spedire un'immagine con un mucchio di SDK e compilatori che non ti servono.
NOTA:leggi questo per saperne di più sulle versioni delle immagini in Dockerfiles in modo da poter scegliere il tag e il digest giusti per le tue esigenze. Idealmente, sceglierai un file Docker che avanza per includere le ultime patch di manutenzione.
Dato questo file docker, creiamo con l'immagine dell'SDK, quindi pubblichiamo e il risultato è di circa 219 mega.
FROM microsoft/dotnet:2.0-sdk as builder
RUN mkdir -p /root/src/app/dockertest
WORKDIR /root/src/app/dockertest
COPY dockertest.csproj .
RUN dotnet restore ./dockertest.csproj
COPY . .
RUN dotnet publish -c release -o published
FROM microsoft/dotnet:2.0.0-runtime
WORKDIR /root/
COPY --from=builder /root/src/app/dockertest/published .
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000/tcp
CMD ["dotnet", "./dockertest.dll"]
Quindi lo salverò come Dockerfile.debian e lo compilerò in questo modo:
> docker build . -t shanselman/dockertestdeb:0.1 -f dockerfile.debian
Con un'app ASP.NET standard questa immagine finisce per essere 219 mega.
Ora cambierò solo una riga e userò il runtime alpine 2.1
FROM microsoft/dotnet-nightly:2.1-runtime-alpine
E costruisci in questo modo:
> docker build . -t shanselman/dockertestalp:0.1 -f dockerfile.alpine
e confronta i due:
> docker images | find /i "dockertest"
shanselman/dockertestalp 0.1 3f2595a6833d 16 minutes ago 82.8MB
shanselman/dockertestdeb 0.1 0d62455c4944 30 minutes ago 219MB
Bello. Circa 83 mega ora invece di 219 mega per un'app Web Hello World. Ora l'idea di un micro il servizio è più fattibile!
Per favore, vai al problema di GitHub qui https://github.com/dotnet/dotnet-docker-nightly/issues/500 e offri i tuoi pensieri e risultati mentre testi queste immagini Alpine. Inoltre, sei interessato a un "-debian-slim?" Sarebbe a metà strada per Alpine ma non così pesante come solo -debian.
Molte cose fantastiche accadono intorno a .NET e Docker. Assicurati di controllare anche il post di Jeff Fritz sulla creazione di un container Windows ASP.NET Core minimo per vedere come puoi schiacciare le applicazioni .(full) Framework in esecuzione anche su container Windows. Ad esempio, le immagini di Windows Nano Server sono compresse solo a 93 mega .
Sponsor: Ottieni l'ultima anteprima di JetBrains Rider per il supporto .NET Core 2.0, il monitoraggio del valore e il monitoraggio delle chiamate, MSTest runner, nuove ispezioni del codice e refactoring e la visualizzazione Stack paralleli nel debugger.