Dotnet-docker: .NET Core 2.1 Docker Image Updates

[MichaelSimons]

.NET Core 2.1 Docker Image Updates

We have consolidating the set of Docker Hub repositories that we use for .NET Core and ASP.NET Core. We will use microsoft/dotnet as the only repository that we publish to for .NET Core 2.1 and later releases.

We added a set of environment variables to .NET Core images to make it easier to host ASP.NET Core sites at any .NET Core image layer and to enable dotnet watch in SDK container images without additional configuration.

Alpine and ARM32 image variants have been added and are supported.

.NET Core Docker Samples have been moved to the dotnet/dotnet-docker repo. The samples have been updated for .NET Core 2.1. New samples have been added, including Hosting ASP.NET Core Images with Docker over HTTPS.

Details

The following changes have been made as part of the .NET Core 2.1 release.

Repo consolidation

.NET Core and ASP.NET Core images will be published to the microsoft/dotnet Docker Hub repo for .NET Core 2.1 and later releases. Co-location of images improves image discovery. The .NET Core runtime and SDK images are already co-located. We are adding the ASP.NET Core runtime images to the microsoft/dotnet repo as a third image type. We are no longer producing the microsoft/aspnetcore-build image with .NET Core 2.1.

The following three tags are now available at the microsoft/dotnet repo:

• 2.1-sdk
• 2.1-aspnetcore-runtime
• 2.1-runtime

Environment variables enable new scenarios

We added a set of environment variables to .NET Core docker images, for .NET Core 2.1 and later. These environment variables enable more scenarios to work without additional configuration, such as developing ASP.NET Core applications in a container.

New sdk image environment variables (example)

• ASPNETCORE_URLS=http://+:80
• DOTNET_RUNNING_IN_CONTAINER=true
• DOTNET_USE_POLLING_FILE_WATCHER=true

New Linux runtime-deps image environment variables (example)

• ASPNETCORE_URLS=http://+:80
• DOTNET_RUNNING_IN_CONTAINER=true

New Windows runtime image environment variables (example)

• ASPNETCORE_URLS=http://+:80
• DOTNET_RUNNING_IN_CONTAINER=true

New image variants

Alpine and ARM32 image variants have been added and are supported as part of the .NET Core 2.1 release.

For Alpine, you must use specific tags to create Alpine-based images, such as 2.1-runtime-alpine.

For ARM32, you can use the regular multi-arch tags, like 2.1-runtime and 2.1-sdk if you are building on an ARM32 device. If you are building on another type of machine, you need to use ARM32-specific tags for the runtime images you create, such as 2.1-runtime-bionic-arm32v7 (for Ubuntu 18.04).

Related repos

The following repos are related to this announcement:

• microsoft/aspnetcore
• microsoft/aspnetcore-build
• microsoft/dotnet/

[steveoh]

I'm still having a hard time with ASPNETCORE_URLS=http://+:80 with the new images.

I have a port conflict on my machine and want to expose a different port than 80. Let's say 1337 for fun.

Dockerfile

ENV ASPNETCORE_URLS=http://+:1337
ENV DOTNET_RUNNING_IN_CONTAINER=true # does this need to be here?
ENV ASPNETCORE_PREFERHOSTINGURLS=false # does this need to be here?
EXPOSE 1337

docker-compose.override.yml

ports:
  - "1337"

The env variables do not seem to help. Can you help me not chase my tail anymore?

[MichaelSimons]

@steveoh, are you referring to a port conflict on the Docker host machine or a port conflict within the image? If the port conflict is within the image, can you explain where the conflict is coming from?

[birkmose]

Guys, I'm wondering why the alpine 2.1 runtime-deps has

DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true

I am currently migrating some aspnetcore apps to 2.1, and receive errors from System.Data.SqlClient.TdsParser.ThrowUnsupportedCollationEncountered when using the SqlClient.

Simply changing DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false, and running

apk add icu

solves the problem for me, but I'm curious about the reason for disabling this specifically
in the alpine runtime? (My app ran straight away in the debian based runtimes for instance).

[MichaelSimons]

@birkmose - you can read about the reasoning in #371. The gist is keeping the image small and having users add on the optional components that are not needed in the majority of scenarios. As noted in the issue we are seeking feedback on the DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true decision.

[MichaelSimons]

@steveoh, Changing the URL and port should be easy however you shouldn't need to change your image configuration at all. Why not just change what port is used on the host machine? You can use docker run -p<your desired host port>:80 to pick any port to use on the host machine. The host port will get mapped to port 80 within the running container. You could also use the -P option to have docker automatically pick an available host port but it requires the image ports to be EXPOSEd. See https://docs.docker.com/engine/reference/run/#expose-incoming-ports

[MichaelSimons]

@steveoh - you can still use docker-compose to change the host/container port mapping.

You should be able to reconfigure the image via the following, unless you have designed your app to pickup the port by some other means.

ENV ASPNETCORE_URLS=http://+:1337
EXPOSE 1337

Your docker-compose doesn't look right to me given the behavior you want.

I also want the docker image to say now listening on the correct port when it starts up so I can command click the link to see the website.

ports:
  - "1337"

You are only specifying the container port. When you only specify the container port, Docker will auto-assign the host port. You can verify this by running your app and then checking the host port via docker ps or docker port. I think you will want to specify 1337:1337 instead.

[steveoh]

@MichaelSimons yes you are correct. I thought that was shorthand for 1337:1337 but it's not.

Either specify both ports (HOST:CONTAINER), or just the container port (an ephemeral host port is chosen).

docker ps

that shows the host and port are set correctly.

Dockerfile

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
ENV ASPNETCORE_URLS=http://[::]:1337
EXPOSE 1337

The app is designed to pick up the port by default I believe. I am assuming from the docker image environment variable.

    public class Program
    {
        public static void Main(string[] args)
        {
            CreateWebHostBuilder(args).Build().Run();
        }

        public static IWebHostBuilder CreateWebHostBuilder(string[] args)
        {
            return WebHost.CreateDefaultBuilder(args)
                          .UseStartup<Startup>();
        }
    }

The defaultbuilder doesn't say much about urls.

Browsing to localost:1337;127.0.0.1:1337;0.0.0.0:1337 gives

What gives?

[MichaelSimons]

@steveoh - try ENV ASPNETCORE_URLS=http://+:1337 instead of ENV ASPNETCORE_URLS=http://[::]:1337

[hpbieker]

Are you running docker on Windows? It runs in a VM with a separate IP, and you must direct your web browser to that IP. No reason to change the port inside the container unless you need to run as non-root, but you might want to set the published port in the compose file to something like 8080:80 to publish the container’s port 80 at the hosts port 8080.

[steveoh]

@MichaelSimons thanks! that did the trick. Oddly enough it still shows as Now listening on: http://[::]:1337 in the console but kestrel is now responding on localhost URI's.

I would assume that http://[::] should work? What do you think?

@hpbieker no, this is running on osx.

[TomasEkeli]

I've tried upgrading from using "microsoft/aspnetcore:2" to "microsoft/dotnet:2.1-aspnetcore-runtime" but now I get the following error when I run the docker image:

Error:
An assembly specified in the application dependencies manifest (web.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

I've tried it with TargetFramework netcoreapp2.0 and netcoreapp2.1 - same error.

Any ideas?

[MichaelSimons]

@TomasEkeli, what does your csproj look like? It sounds like you have an dependency on aspnetcore 2.0.0. e.g. <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" /> If you want to use the microsoft/dotnet:2.1-aspnetcore-runtime it would be best to upgrade your ASP.NET Core dependency to 2.1. The 2.1-aspnetcore-runtime image contains the ASP.NET Core shared runtime for 2.1.

[TomasEkeli]

Yes, you're right @MichaelSimons - it turns out I have some other dependencies being pulled in that I need to upgrade. Thanks!

[ZOXEXIVO]

I change target framework netcoreapp2.0 -> netcoreapp2.1
for project that running on microsoft/dotnet:2.1-runtime container - it fail to run with error:

_Did you mean to run dotnet SDK commands? Please install dotnet SDK from_

Same error for new microsoft/dotnet:2.1-aspnetcore-runtime

[MichaelSimons]

@ZOXEXIVO, Can you provide some specifics on the scenario in which you are encountering this error?
Are you saying the only thing you changed is the target framework from netcoreapp2.0 to netcoreapp2.1? What does your Dockerfile look like? Providing a standalone repo would be the best way to get help.

[ZOXEXIVO]

@MichaelSimons This my bad.
Thank you for help

[MichaelSimons]

@ZOXEXIVO, this error is most likely caused because SomeProject.Web.dll does not exist in your container as expected. To diagnose this, you could comment out your ENTRYPOINT, build your image, and run the resulting container interactively to inspect that SomeProject.Web.dll exists as expected. If you are running with Linux containers, keep in mind case sensitivity matters.

[MichaelSimons]

Closing the announcement - feel free to continue discussions and please log issues for any problems encountered.

[pinkplus]

Hey guys, I want to provide my feedback on the globalization invariant mode in Alpine images.

I believe it's better to

• Add ICU and disable globalization invariant mode
• Or, provide a separate Alpine image that has full globalization features

When I started to use the Alpine image, I expected that it could have performance difference from Debian image, because of a different libc implementation. Any other feature difference should be absorbed and unified by the .NET runtime.

It's misleading to provide an Alpine image that don't have the full features -- that's not the expectation. If you really want to do it to optimize the size, you should provide an image that has globalization features. You should also document it in the main README.md, but having a different variation is probably the best documentation :)