-
Notifications
You must be signed in to change notification settings - Fork 30
.NET Core Alpine Docker Image Ready for Testing #500
Comments
What's the difference between |
@khellang - The The |
JFYI: The split isn't new for Alpine. It's the same split we've had for Debian. |
Right. That's was my suspicion, but hadn't seen the split before stumbling across this post and figured someone else might wonder the same. Thanks! 😄 |
Shouldn't it be microsoft/dotnet:2.1.x-runtime-alpine, given the current stuff is 2.0.0? |
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:
Docker file:
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: |
I am getting |
Are there any plans for an Alpine |
@steve-todorov - yes there is. There is an active PR - #508. It is currently blocked on a product issue. |
@MichaelSimons thanks for your reply! I'll be keeping an eye at #508 in that case. |
@cburman01 @kjbetz |
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. |
Issue moved to dotnet/dotnet-docker #371 via ZenHub |
.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:
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 .NET Core 2.1 is shipped as a Preview, expected to be early 2018.
Details
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.
-deps
-runtime
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
DOTNET_SYSTEM_GLOBALIZATION_INVARIANT
environment variable and install the ICU package. Please check out .NET Core Docker Alpine Production Sample (Preview) to see examples of using this image with and without Globalization Invariant Mode enabled.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.
The text was updated successfully, but these errors were encountered: