dotnet
Consider producing a distroless SDK
Today, we produce distroless variants for all image types except SDK. In thinking more about it, it isn't obvious why that is. The benefits of distroless and the reasons why you might not be able to use it seem to apply equally to runtime as SDK.
I did some basic tests with Mariner. Distroless dropped the size of the image by nearly half and gave me the benefits of non-root. We may want to add the shell back for this scenario, but that's a design/policy point.
For users that use RUN commands solely for dotnet, a distroless SDK seems like 100% win w/no downside. It also means that you get to share layers between runtime and SDK which you cannot w/today's approach (with distroless). So, not only will SDK be smaller, but your overall layer pull for multi-stage build will be MUCH smaller.
[Triage] This is a fine idea with some concrete benefits for download sizes while building Dockerfiles. However, we want to make sure there's enough demand and that the images we produce will meet enough of the SDK's usage scenarios to be worth producing, without being too confusing or difficult to use.
I would like to see this implemented so that we can have a reduced size for our dedicated unit testing image that needs to run [dotnet test] in a CI/CD pipeline.
I have the same use case as jrnelson90 and would also like this for an image used to run dotnet test in a CI pipeline. I could probably live without a shell, though if you wanted to include Bourne shell in an -extras variant (or another affix if that's contrary to this issue and guidance regarding tag naming consistency) for any CI script execution, that'd be cool.
Alternatively, guidance on how to identify what to chisel so we can maintain our own variant (if that's not something you want to own ongoing) would be a fine alternative.
I would like to see this implemented in order to deploy Functions Apps with an isolated .NET runtime.
I would like to see this implemented in order to deploy Functions Apps with an isolated .NET runtime.
@shahin-mameghani-mesh - Can you provide more details on why a distroless sdk is helpful/preferred here?
I'm using the Ubuntu Chiseled runtime image for my .NET applications, but I'm having trouble debugging it with JetBrains Rider. To debug in Docker, I need an SDK image, but there isn't an Ubuntu Chiseled SDK image available.
Using a standard Ubuntu image isn't ideal because it might hide issues that are specific to the Chiseled environment, like problems with culture settings (libicu) or timezones.
Could you please consider providing an Ubuntu Chiseled SDK image? This would help a lot in making sure our debug environment matches the runtime environment exactly.
@alexsteeel, can you share more about why you need the full SDK to debug your application? What exactly happens when you try to use the Ubuntu Chiseled runtime image?
Would adding a package like procps help? It's needed for debugging in VS. Not sure if it's the same story for Rider.
@lbussell, you're right, the runtime image is sufficient for debugging, and an additional SDK image isn't necessary. Thanks for the suggestion!
I looked into the issue using a small example. The final working solution, along with detailed information about the issue and how it was resolved: UbuntuChiseledWorkerService