Provide an official ASP.NET alpine-extra image with globalization support (ICU and tzdata)

[DanielLaberge]

Please reconsider providing an official alpine-extra image for ASP.NET (and runtime) that supports globalization.

This announcement mentions:

We don't plan to offer runtime and aspnet images based on 8.0-jammy-chiseled-extra. We will re-consider that if there is sufficient demand.

Currently, we are either forced to:

• Use a custom alpine base image that adds globalization data as documented by dotnet here. Or:
• Use a debian image (bookworm-slim), which is ~74MB bigger than the custom alpine image with globalization data 👎

This goes against the "Batteries included and Choose your own adventure" themes in the announcement.
We would like to concentrate on developing apps, not maintaining custom containers.

Thank you.

EDIT: For anyone looking to get the smallest image in the meantime, you can use the the runtime-deps:8.0-alpine-extra image like this:

dotnet publish --os linux-musl --self-contained true -p:ContainerBaseImage=mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine-extra -p:PublishProfile=DefaultContainer

[mthalman]

@DanielLaberge - based on the referenced issue at dotnet/sdk-container-builds#512, I'm assuming this is in the context of wanting to use the SDK container publishing feature and that you don't want to have to maintain your own Dockerfile. Is that correct?

[DanielLaberge]

@mthalman That is correct. I will edit the issue to reflect that.

[richlander]

You could use self-contained deployment with the runtime-deps:8.0-alpine-extra image with SDK OCI publishing. Can you share why that isn't satisfactory?

This goes against the "Batteries included and Choose your own adventure" themes in the announcement.

I'm glad that folks read our announcements!

[DanielLaberge]

@richlander I will gladly try this and report my results if someone could point me to relevant documentation on how to achieve this with an ASP.NET app.

I've tried adding the following to my .csproj: <ContainerBaseImage>mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine-extra</ContainerBaseImage>

Then building with dotnet publish --os linux --arch x64 --self-contained true -p:PublishProfile=DefaultContainer -c Release
But running the container produces this error: exec /app/MyAppName: no such file or directory

I assume I must be missing some step, but I couldn't find relevant documentation or examples.

[lbussell]

Could you try adding the argument --self-contained true to your publish command, or adding <SelfContained>true</SelfContained> property to your csproj?

Also adding @baronfel.

[DanielLaberge]

@lbussell I indeed had the <SelfContained>true</SelfContained> property in my .csproj but forgot to mention it in my last comment. I'll edit it to avoid further confusion.

[DanielLaberge]

I have reproduced the same error with a blank ASP.NET template like so:

mkdir aspnet-alpine-extra-test && cd aspnet-alpine-extra-test
dotnet new webapp
dotnet publish --os linux --arch x64 --self-contained true -p:ContainerBaseImage=mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine-extra -p:PublishProfile=DefaultContainer -c Release
docker run aspnet-alpine-extra-test:latest
exec /app/aspnet-alpine-extra-test: no such file or directory

However, if I don't specify the ContainerBaseImage, it defaults to mcr.microsoft.com/dotnet/runtime-deps:8.0.0-rc.2 (based on Debian 12 instead of runtime-deps:8.0-alpine-extra) and then runs successfully. Clearly there is something missing.

[richlander]

Switch to:

dotnet publish --os linux-musl 

You are saying "I want an app compatible with Linux glibc" when you want one compatible with musl (what Alpine uses).

If you are building on x64, then you can skip --arch x64. Also -c Release can be skipped. That's now the default for dotnet publish.

After we get this resolved, you can try trimming to try to make the image smaller, with -p:PublishTrimmed=true.

We have not rejected the overall request. It makes sense to see if this works.

[DanielLaberge]

Specifying --os linux-musl does indeed work. Thank you for that.

I wasn't aware of this detail, being unfamiliar with alpine images.
The error message produced when calling dotnet publish --self-contained -p:PublishProfile=DefaultContainer without specifying --os is misleading in that regard as it doesn't mention 'linux-musl'.

error MSB4018: Microsoft.NET.Build.Containers.BaseImageNotFoundException: The RuntimeIden 
tifier 'win-x64' is not supported by dotnet/runtime-deps:8.0-alpine-extra. 
The supported RuntimeIdentifiers are linux-x64,linux-arm,linux-arm64

I think this discussion illustrates why an official aspnet alpine-extra image might be helpful to the community; allowing everyone to benefit from the smallest possible image without this kind of friction and specific required knowledge. It would be as simple as setting -p:ContainerFamily=alpine-extra.

Thank you for the consideration.