-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expand support for musl-based containers #301
Comments
This may be a good case for the usage of annotations. They allow for metadata to be attached to various registry objects. I'm waiting to hear back from the MAR team on the status of annotation support. |
I have conflicting thoughts about the use of annotations:
|
This will likely depend on #401 a lot to get done. We should probably take the
No change is required during manifest list selection, because all of the |
<PropertyGroup>
<ContainerFamily Condition="'$(ContainerFamily)' == '' and '$(RuntimeIdentifier)' != '' and $(RuntimeIdentifier.Contains('-musl-'))">alpine</ContainerFamily>
</PropertyGroup> |
I just ran into this while working on some demos. |
With 8.0.200, targeting |
As of 0.3.2 if a user targets a musl-based container (e.g.
mcr.microsoft.com/dotnet/aspnet:7.0-alpine
) they cannot use a musl-based RID (e.g.linux-musl-x64
) to ensure the correct assets get built for that runtime. We present them an error saying that onlylinux-x64, linux-arm, and linux-arm64
RIDs are valid for that image. This is because the RIDs we generate for comparison purposes based on the manifest list for the7.0-alpine
tag of that image do not take musl into account. If the user follows our error messages and uses a non-musl Linux RID, the generated container image will not launch because the entrypoint (/app/<projectname>
) is not launchable by the shell due to the libc incompatibility.There is no data point on the manifest list or the individual manifests that would tell us that the image is musl based, so we can't change our RID-comparison generation to take this into account. The best guess we have could be to look for
alpine
in the image tag name, but that feels brittle and incomplete.The user's only out right now is to explicitly specify a more detailed image tag name. In the example above, the user would change from
mcr.microsoft.com/dotnet/aspnet:7.0-alpine
tomcr.microsoft.com/dotnet/aspnet:7.0-alpine-amd64
.We should document this caveat and consult with @mthalman and other container gurus to see if there is any data point we can drive inference logic from.
Resources
manifest list for the 7.0-alpine tag of the aspnet image
manifest for the amd64 variant in that same list
The text was updated successfully, but these errors were encountered: