Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
.NET Core Alpine Docker Image Ready for Testing #500
.NET Core Alpine Docker Image Ready for Testing
An Alpine-based Docker image is now available for .NET Core. Alpine is much smaller than Debian, which we have used for the .NET Core base image to date. There have been many requests for an Alpine image. We are pleased to make it available. Please check out .NET Core Docker Alpine Production Sample (Preview) to see examples of using this image.
We have added two new images:
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 .NET Core 2.1 is shipped as a Preview, expected to be early 2018.
The primary goal of Alpine is very small deployments. We have been considering various design decisions to make .NET Core Alpine base images as small as possible to align with that. In this first iteration, we enabled .NET Core 2.0 Globalization Invariant Mode in order to reduce the default size of the image. This change reduced the image by ~30MB. You can see the reduction in size for .NET Core images relative to Debian in the following table.
Note: The compressed size is what you will see in a registry and is the wire-size cost.
We are also considering saving more space by native-compiling fewer assemblies. .NET Core runtime assemblies are native-compiled with the crossgen tool in the Ready2Run format. Native-compiled code delivers superior startup performance but at the cost of 2-3x larger files. We have the opportunity to compile less, skipping compiling assemblies in part or in whole. We believe that we can save at least another 10MB through compiling less without a material drop in performance. For scenarios that value size over startup or where wire cost is significant, it may be valuable to aggressively reduce the number/% of compilation.
Alpine images are only available for .NET Core 2.1. At the current time, only Runtime images are available. We intend to offer SDK images at a later date.
Use cases that cannot tolerate Globalization invariant mode can reset the
Call to Action
Please test your workloads with the new Alpine image. In particular, we want to know if enabling .NET Core Globalization Invariant Mode is acceptable/appreciated.
referenced this issue
Nov 21, 2017
We are pushing the exact same form/scheme of tags as always. See @ https://hub.docker.com/r/microsoft/dotnet-nightly/
For the most part, we offer four types of tags:
We believe that most scenarios are best served by referencing a specific digest or a specific major/minor, as is used in the example that you are referencing. The specific patch tags can be useful, for sure, but you have to realize that the OS is being patched underneath you. So, the scenario for the specific patch is that you want to opt-in to .NET Core patch updates but you are fine with automatic OS updates. And by "automatic", I mean automatic in environments that
For samples, the specific major/minor tags is really the only option available to us. We don't want to update samples for each .NET Core patch update and we certainly don't want people pulling older (less secure) patches in the case we get lazy and don't update those samples.
We may choose to stop publishing the specific patch tags for .NET Core 3.0 (meaning not for .NET Core 2.x).
Will the -runtime image work for aspnet core applications? I was able to build from the image fine but am getting this when running the container:
The application is just a barebones aspnet core application template from visual studio.
The current image is exposing 5000 as the default port. We need to explicitly expose 80 or 8080 or any other custom port using the UseUrls method. The Microsoft/aspnetcore:2.0 image was able to map the ports exposed in Dockerfile without explicitly specifying the ports in BuildWebHost method. I tried upgrading to Alpine based image recently and had to make changes to expose specific ports (http://www.handsonarchitect.com/2017/12/migrate-dotnet-core-docker-image-to.html)
Will the stable version of Alpine based image support this feature of mapping ports from Dockerfile?
@cburman01 You're building / compiling your app with 2.0 and then trying to run with 2.1. You'll probably need to change your first line to something like this:
In the hope someone will save alot of time and frustration, I am sharing my minimal solution to creating, publishing and running a web project.
The issues that I have found and handled is:
dotnet new mvc? I failed horribly there. Have not tried with a custom made .csproj file or as a self-contained application though.