Skip to content
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

Support pivoting on OS platform and Architecture for image selection #91

Closed
baronfel opened this issue Aug 9, 2022 · 11 comments
Closed
Assignees
Labels
Area: Library Tasks and stories around the image and layer manipulation library

Comments

@baronfel
Copy link
Member

baronfel commented Aug 9, 2022

Right now we explicitly support Linux/x64 container images - we should instead take into account the OS and Architecture the user provides and pick the correct 'base image' from the manifest list (if there is one on the base image).

We'll need to investigate what level of impact this has on picking the correct base image, but this will also have an impact on

  • WorkingDirectory
  • EntryPoint

Overlaps with #117

@baronfel baronfel added the Area: Library Tasks and stories around the image and layer manipulation library label Aug 26, 2022
@bgiromini
Copy link

I assume this is still not supported with the release of dotnet 7 today?

@rainersigwald
Copy link
Member

@bgiromini correct--the 0.2 version of the package is still linux-x64 only. But this is definitely still on the to-do list!

@MrRickwi
Copy link

I tried to use debian.11 as OS - which is still Linux - but didn't work. Would be nice to see at least support for all Linux-like OSs in very near future - because we have packages in our project which have nothing in runtimes/linux-x64, but e.g. runtimes/debian.11-x64

@baronfel
Copy link
Member Author

Thanks for the feedback @MrRickwi - I'm working on this in #247 and one of the open questions I was thinking about was 'how seriously do we need to handle RID support/compatibility'? Your response makes me think we need to fully support it.

@Zigby
Copy link

Zigby commented Nov 30, 2022

I was hoping it would work to publish arm images like this

dotnet publish --os linux --arch arm64 

Is it correct that this issue will address publishing linux-arm64?

@baronfel
Copy link
Member Author

Yep, exactly - right now when you publish, if the image you choose (let's take mcr.microsoft.com/dotnet/aspnet:7.0 as our example) is a 'manifest list' (meaning it supports multiple architectures), we don't understand that and instead we end up picking the 'first' image in the manifest list. This is usually a linux-x64 image. You as a user could explicitly pick an arm64 version of this image right now via setting the ContainerBaseImage property, but we would instead like to read the RID that you specify and use it to pick the most appropriate base image if the image you chose supports multiple architectures.

@Zigby
Copy link

Zigby commented Dec 2, 2022

If I understood correctly I should be able to create arm64 images by explicitly specifying the ContainerBaseImage. I cannot get it to work so here is what I am doing ...
I am omitting the architecture from the command line
dotnet publish --os linux -p:PublishProfile=DefaultContainer
and specify the container image in the csproj file (just picked what I thought would be appropriate)

 <ContainerBaseImage>mcr.microsoft.com/dotnet/aspnet:7.0-bullseye-slim-arm64v8</ContainerBaseImage>

I get the following error message
The Microsoft.NET.Build.Containers package does not (yet) support publishing for linux-arm64

If I specify "--arch x64" it produces an image but it does not properly run on my arm computer.

Do I need to wait for a fix, or am I doing it wrong?

@baronfel
Copy link
Member Author

baronfel commented Dec 2, 2022

@Zigby you're exactly right - I forgot we explicitly locked that down for the initial release here. My apologies! So yes, you're blocked until we release #247.

@Zigby
Copy link

Zigby commented Dec 6, 2022

Thanks for the clarification and prompt response. I will stick to docker files for a little longer...

@baronfel baronfel added this to the 7.0.200/VS17.5 milestone Dec 7, 2022
@baronfel
Copy link
Member Author

We're currently planning to freeze the RID graph and make RIDs no longer distro-specific. As a result, we're not going to go to full detail in this project to support e.g. ubuntu22.04-x64 for example. Instead, for publishing containers you'd specify linux-x64 (or linux-arm64 or another supported RID for the container manifest list). If a RID is specified that there is not match for on the discovered manifest list, an error will be raised specifying the valid RIDs for the manifest list.

@baronfel baronfel self-assigned this Dec 20, 2022
@baronfel
Copy link
Member Author

Fixed in #247, out now in version 0.3.2 of the package!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Library Tasks and stories around the image and layer manipulation library
Projects
None yet
Development

No branches or pull requests

5 participants