.NET Core Alpine Docker Image Ready for Testing

[MichaelSimons]

@richlander commented on Tue Nov 21 2017

.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

• dotnet/dotnet-docker-nightly #480
• dotnet/announcements #20
• dotnet/dotnet-docker-samples #94

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.

2.1 Image	Debian	Alpine
-deps	153MB (68MB compressed)	13.8 MB (6MB compressed)
-runtime	222MB (96MB compressed)	82.5 (34MB compressed)

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.

---

@khellang commented on Tue Nov 21 2017

What's the difference between runtime and runtime-deps and when would you use each? I don't think this comes through in the post...

---

@MichaelSimons commented on Tue Nov 21 2017

@khellang - 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

---

@richlander commented on Tue Nov 21 2017

JFYI: The split isn't new for Alpine. It's the same split we've had for Debian.

---

@khellang commented on Tue Nov 21 2017

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! 😄

---

@shanselman commented on Wed Nov 22 2017

Shouldn't it be microsoft/dotnet:2.1.x-runtime-alpine, given the current stuff is 2.0.0?

---

@richlander commented on Wed Nov 22 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:

• Specific digest (this isn't actually a tag)
• Specific patch
• Specific major/minor (roll-forward on patch)
• Roll-forward (multiple variants of this one)

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 docker pull, either by your explicit action or on your behalf.

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).

---

@cburman01 commented on Wed Dec 06 2017

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:

Error:
  An assembly specified in the application dependencies manifest (WebApplication7.deps.json) was not found:
    package: 'Microsoft.ApplicationInsights.AspNetCore', version: '2.1.1'
    path: 'lib/netstandard1.6/Microsoft.ApplicationInsights.AspNetCore.dll'
  This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
    aspnetcore-store-2.0.0-linux-x64.xml;aspnetcore-store-2.0.0-osx-x64.xml;aspnetcore-store-2.0.0-win7-x64.xml;aspnetcore-store-2.0.0-win7-x86.xml

Docker file:

FROM microsoft/dotnet:2.0-sdk as builder

RUN mkdir -p /root/src/app/WebApplication7
WORKDIR /root/src/app/WebApplication7

COPY . .
RUN dotnet restore ./WebApplication7.csproj

COPY . .
RUN dotnet publish -c release -o published

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


WORKDIR /root/
COPY --from=builder /root/src/app/WebApplication7/published .
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000/tcp
CMD ["dotnet", "./WebApplication7.dll"]

The application is just a barebones aspnet core application template from visual studio.

---

@NileshGule commented on Sat Dec 09 2017

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?

---

@kjbetz commented on Wed Dec 13 2017

@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: FROM microsoft/dotnet-nightly:2.1-sdk as builder

https://hub.docker.com/r/microsoft/dotnet-nightly/

---

@ChaosEngine commented on Tue Dec 26 2017

I am getting segmentation fault when building with dotnet-nightly:2.1-sdk and running under 2.1-runtime-alpine.
Just by using plain dotnet new mvc && dotnet publish && dotnet app.dll.
If needed, I could prepare full repro info dump.

---

@steve-todorov commented on Wed Jan 31 2018

Are there any plans for an Alpine sdk version as well?

---

@MichaelSimons commented on Wed Jan 31 2018

@steve-todorov - yes there is. There is an active PR - dotnet/dotnet-docker-nightly#508. It is currently blocked on a product issue.

---

@steve-todorov commented on Thu Feb 01 2018

@MichaelSimons thanks for your reply! I'll be keeping an eye at #508 in that case.

---

@ChristianRMKoerber commented on Tue Feb 06 2018

@cburman01 @kjbetz
I am getting exactly the same error regardless of whether I am using dotnet-nightly:2.1-sdk or microsoft/dotnet:2.0-sdk.

---

@isberg commented on Fri Feb 09 2018

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:

• switched package Microsoft.AspNetCore.App to Microsoft.AspNetCore.App
• installed missing libuv.so in alpine
• set ASPNETCORE_URLS

FROM microsoft/dotnet-nightly:2.1-sdk AS builder

WORKDIR /src
RUN dotnet new web \
 && sed -i 's/Microsoft.AspNetCore.App/Microsoft.AspNetCore/g' *.csproj \
 && dotnet publish -c Release -o /app


FROM microsoft/dotnet-nightly:2.1-runtime-alpine AS runtime
RUN apk add --no-cache libuv \
 && ln -s /usr/lib/libuv.so.1 /usr/lib/libuv.so
ENV ASPNETCORE_URLS http://+:80

WORKDIR /app
COPY --from=builder /app .
ENTRYPOINT ["dotnet", "src.dll"]

dotnet new mvc? I failed horribly there. Have not tried with a custom made .csproj file or as a self-contained application though.

[ghost]

Why is Alpine support bound to Docker? I just want to run dotnet core on Alpine and Docker is not used at all on my systems. How can I do that?

[MichaelSimons]

@bootrino - You can install .NET Core on an Alpine machine yourself following the steps done in the Dockerfiles. Install the prereqs as is done in the runtime-deps image, then install the runtime as is done in the runtime image.

[ghost]

Thanks @MichaelSimons although this "Docker first" approach is puzzling and hopefully not a trend... it seems strange have to go back and work out how a docker implementation works to do an ordinary operating system installation... hopefully when Alpine support is released it is not a Docker first thing.

[richlander]

Alpine builds are available here: https://github.com/dotnet/core-setup/blob/master/README.md

[FranklinYu]

Currently it is based on Alpine 3.6, but 3.7 is already available. After migrate, we no longer need Edge branch of Alpine like here.

[MichaelSimons]

@janvorli - Are there plans to move to Alpine 3.7 for testing and official builds?

[janvorli]

I would eventually like to do that, but after the 2.1 is out. And we are thinking about moving from Alpine specific packages to MUSL portable ones (that means packages that would work on all distros based on MUSL c library).