Scott Hanselman

Trying out new .NET Core Alpine Docker Images

November 22, 2017 Comment on this post [11] Posted in Docker | DotNetCore | Open Source
Sponsored By

Docker ContainersI blogged recently about optimizing .NET and ASP.NET Docker files sizes. .NET Core 2.0 has previously been built on a Debian image but today there is preview image with .NET Core 2.1 nightlies using Alpine. You can read about the announcement here about this new Alpine preview image. There's also a good rollup post on .NET and Docker.

They have added two new images:

  • 2.1-runtime-alpine
  • 2.1-runtime-deps-alpine

Alpine support is part of the .NET Core 2.1 release. .NET Core 2.1 images are currently provided at the microsoft/dotnet-nightly repo, including the new Alpine images. .NET Core 2.1 images will be promoted to the microsoft/dotnet repo when released in 2018.

NOTE: The -runtime-deps- image contains the dependancies needed for a .NET Core application, but NOT the .NET Core runtime itself. This is the image you'd use if your app was a self-contained application that included a copy of the .NET Core runtime. This is apps published with -r [runtimeid]. Most folks will use the -runtime- image that included the full .NET Core runtime. To be clear:

- The runtime image contains the .NET Core runtime and is intended to run Framework-Dependent Deployed applications - see sample

- The runtime-deps image contains just the native dependencies needed by .NET Core and is intended to run Self-Contained Deployed applications - see sample

It's best with .NET Core to use multi-stage build files, so you have one container that builds your app and one that contains the results of that build. That way you don't end up shipping an image with a bunch of SDKs and compilers you don't need.

NOTE: Read this to learn more about image versions in Dockerfiles so you can pick the right tag and digest for your needs. Ideally you'll pick a docker file that rolls forward to include the latest servicing patches.

Given this docker file, we build with the SDK image, then publish, and the result is about 219megs.

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"]

Then I'll save this as Dockerfile.debian and build like this:

> docker build . -t shanselman/dockertestdeb:0.1 -f dockerfile.debian

With a standard ASP.NET app this image ends up being 219 megs.

Now I'll just change one line, and use the 2.1 alpine runtime

FROM microsoft/dotnet-nightly:2.1-runtime-alpine

And build like this:

> docker build . -t shanselman/dockertestalp:0.1 -f dockerfile.alpine

and compare the two:

> docker images | find /i "dockertest"
shanselman/dockertestalp 0.1 3f2595a6833d 16 minutes ago 82.8MB
shanselman/dockertestdeb 0.1 0d62455c4944 30 minutes ago 219MB

Nice. About 83 megs now rather than 219 megs for a Hello World web app. Now the idea of a microservice is more feasible!

Please do head over to the GitHub issue here https://github.com/dotnet/dotnet-docker-nightly/issues/500 and offer your thoughts and results as you test these Alpine images. Also, are you interested in a "-debian-slim?" It would be halfway to Alpine but not as heavy as just -debian.

Lots of great stuff happening around .NET and Docker. Be sure to also check out Jeff Fritz's post on creating a minimal ASP.NET Core Windows Container to see how you can squish .(full) Framework applications running on Windows containers as well. For example, the Windows Nano Server images are just 93 megs compressed.


Sponsor: Get the latest JetBrains Rider preview for .NET Core 2.0 support, Value Tracking and Call Tracking, MSTest runner, new code inspections and refactorings, and the Parallel Stacks view in debugger.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
November 22, 2017 23:38
What's the size if you publish a self contained app?
November 22, 2017 23:53
JC - it was about 113 but I didn’t yet do the two kinds of tree trimming.
November 23, 2017 1:40
Can't wait to see a docker images Dotnet core native app ( 82.8MB) it will bee history to tell.
Thank you Microsoft i can't be Proud to be c# developer (performance + opensource + first class tools + multi-platform )
its like i have all what my java friend use to brag about but butter they have oracle
November 23, 2017 17:04
Any plans for a production version of ODBC connectivity? It's hard to build all those trendy apps working on data without a good generic database interface. Java is doing much better with JDBC :/
November 23, 2017 17:10
Thank you for the great post Scott!! This size is really a game changer. My current image with 299 MB isn't too big, but every MB counts :-)

I know that you are a Rasbperry fan like myself: do you know if there are any plans to use .NET Core Native for any other kind of targets and not just universal windows apps? The pro-arguments about using native code for UWPs apply for targets like a Raspberry.
November 23, 2017 21:34
I have an example of using a self contained app with alpine at https://github.com/annymsMthd/small-docker-test

Using ILLink.Tasks The size comes out to about 49.8MB
November 27, 2017 3:16
Hi Scott, could you please share how the csproj file looks like? Because I tested the Alpine image with my app and I get an error saying "The specified framework 'Microsoft.NETCore.App', version '2.0.0' was not found."

This is the csproj:


<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp2.0;net461;net451</TargetFrameworks>
<RuntimeIdentifiers>win-x64;linux-x64;linux-arm;osx-x64</RuntimeIdentifiers>
</PropertyGroup>
</Project>


In the Dockerfile I use
microsoft/dotnet:2.0-sdk-jessie
for building the app and
microsoft/dotnet-nightly:2.1-runtime-alpine
for running the app.

When using
microsoft/dotnet:2.0-runtime
for running, everything works fine.

For more info check out the comment I created in a related issue on GitHub: https://github.com/dotnet/cli/issues/7901#issuecomment-346940892
November 29, 2017 5:41
Can you explain the COPY . . line in the dockerfile?
November 29, 2017 16:46
I figured it out.

COPY <build context> <workdir context>
November 30, 2017 5:02
Now once your team is that the one defensive you continue to get to manage your players with the joystick however the 3 buttons modification to modify Guard and Block. Real life street courts available to play in The One include Cara Efektif Mengobati Kelenjar Tiroid Secara Alami Venice Beach California and Rucker Park in New York.. My suggestion could sure for having an organisation line a number of kind of voicemail or at truly a message machine.
December 02, 2017 19:05
Thanks Scott.

Am I being dumb here, because I feel like I'm missing something. What is Alpine? To me it just seems like this word has appeared signifying something new, but with no explanation of what this new thing actually is. The readme on the docker samples github doesn't explain it either.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.