Closed richlander closed 1 year ago
[Triage]
icu
. Ideally, the UX would be improved to the point where the need of an icu-specific image type goes away. In that case, we could always discontinue that image type for the next major .NET version.ICU is written in C++ and brings in dependency on C++ runtime.
Is the C++ runtime the only thing that differentiates between aot-deps and runtime-deps? If it is the case, aot-deps w/ ICU is going to be identical to runtime-deps w/ ICU.
Great observation.
See runtime-deps:chiseled -> https://github.com/dotnet/dotnet-docker/blob/main/src/runtime-deps/8.0/jammy-chiseled/amd64/Dockerfile
You can see that we went the "Alpine route" and removed (didn't add) ICU.
I am now thinking that we should do the following:
aot-deps:chiseled
-- no ICUruntime-deps:chiseled
has ICUThis will have a couple advantages:
We made this ICU decision before .NET 7 shipped. It was an obvious decision at the time and then we forgot about it and didn't revisit it. W/more information available, this seems like a better plan. If folks want CoreCLR + smaller, then got aot-deps + self-contained + trimming.
Works?
Works?
What percentage of apps can utilize Native AOT? I has the understanding that there are feature gaps that prevent all apps from using it.
Good question, but that's not what I meant.
Much higher number of users can switch to chiseled (in CoreCLR land) from regular Ubuntu w/no fanfare.
I meant that our goal is to enable a high % of apps that are currently targeting Ubuntu or Debian (with CoreCLR) to switch to our chiseled images, still with CoreCLR. Adding ICU back will help with that. It also means we don't have to document take-backs. We never really discussed that. To be clear, Alpine users can switch to, but that's outside this discussion.
Your proposal specifically calls out Chiseled images as the goal is to promote migration from "full/regular" Ubuntu/Debian. Does it include adding ICU to the alpine and mariner runtime-deps as well?
I'd propose that we follow the same model for Mariner as I'm proposing for Ubuntu. It enables all the scenarios.
I'd leave Alpine as-is until we fund Alpine distroless and then reconsider.
Sorry, I got this a bit wrong. It's a little more complicated than I thought.
To enable all the scenarios, we need three not two deps
images:
The first two can go into runtime-deps
and the last into aot-deps
.
I assume the sdk-container-builds component can inference all three of these.
/cc @baronfel
@richlander, your last comments are not clear to me. You enumerated three scenarios and called out the need for three images yet said the first two scenarios can be covered by runtime-deps. Can you please clarify?
@richlander, your last comments are not clear to me. You enumerated three scenarios and called out the need for three images yet said the first two scenarios can be covered by runtime-deps. Can you please clarify?
I think @richlander left out the "ICU + no stdc++ -- Native AOT + ICU" scenario which would be the third image: aot-icu-deps
What I meant is that the first two scenarios apply to CoreCLR, so make sense in runtime-deps
(as a repo). The last scenario doesn't apply to CoreCLR so doesn't below in runtime-deps
.
ICU + no stdc++
There is no such scenario.
ICU is written in C++ and brings in dependency on C++ runtime.
That's what Jan said.
ICU + no stdc++
There is no such scenario.
Ok, I understand that now.
To enable all the scenarios, we need three not two deps images:
I'm still confused. What are the 3 images? Can you refer to actual names rather than scenario descriptions?
For sure.
runtime-deps:8.0-jammy-chiseled-icu
runtime-deps:8.0-jammy-chiseled
aot-deps:8.0-jammy-chiseled
Same order as above.
There could be some discussion about whether the default chiseled should contain ICU or not. I think we should probably invert it. I started with this scheme to make it easier to talk about. Once we get past this piece (agreeing on the three images), we can talk about whether including ICU should be the default.
I changed my mind. I think the tag scheme above is best. It's simple and accurately descriptive.
The key thing we want is that aspnet
and runtime
images are built on the image with ICU to enable low-friction adoption of chiseled images.
Our story should be: "Chiseled images give you low size, low CVEs, glibc, and ICU. And if you want to go even smaller (with some more effort), we've got good options for that."
That means that runtime
and aspnet
tags would be 8.0-jammy-chiseled-icu
.
I see a few potential UX issues with the proposal that I would like to raise and discuss.
It all comes back to how incredibly hard tagging can be :)
One option is that we could dual tag (appropriate) images in both aot-deps and runtime-deps. That would help.
We have a couple options:
-slim
.In my ideal world, we do the following:
Given the popularity of Alpine, I don't think we can do this, at least as acutely as the wording suggests. We'd need a release were we produce both Alpine variants (for fx-dependent). That said, I think this model is the right one. Also, ASP.NET Core doesn't yet the trimming story that this model would demand.
Let's try some options.
This aligns closest with status quo.
runtime-deps:8.0-jammy-chiseled-icu
runtime-deps:8.0-jammy-chiseled
aot-deps:8.0-jammy-chiseled-icu
aot-deps:8.0-jammy-chiseled
First and third images are the same (re-tagged).
We'd then also have:
runtime:8.0-jammy-chiseled-icu
aspnet:8.0-jammy-chiseled-icu
runtime-deps:8.0-jammy-chiseled
runtime-deps:8.0-jammy-chiseled-min
aot-deps:8.0-jammy-chiseled
aot-deps:8.0-jammy-chiseled-min
Note: -min
is proposed as a (descriptive) placeholder.
First and third images are the same (re-tagged).
We'd then also have:
runtime:8.0-jammy-chiseled
aspnet:8.0-jammy-chiseled
He's a concrete proposal.
aot-deps
and runtime-deps
will be considered to be in the same layer.aot-deps
ICU is not installed by default. All of these images are on the distroless plan, even Alpine.
aot-deps:8.0-alpine
aot-deps:8.0-alpine-icu
aot-deps:8.0-cbl-mariner2.0-distroless
aot-deps:8.0-cbl-mariner2.0-distroless-icu
aot-deps:8.0-jammy-chiseled
aot-deps:8.0-jammy-chiseled-icu
Note: ICU images are just re-tags between aot-deps
and runtime-deps
and only differ by repo names (tags are identical).
runtime-deps
ICU is installed by default, except for distroless and Alpine (for historical reasons).
runtime-deps:8.0-alpine
runtime-deps:8.0-alpine-icu
runtime-deps:8.0-bookworm-slim
runtime-deps:8.0-cbl-mariner2.0-distroless
runtime-deps:8.0-cbl-mariner2.0-distroless-icu
runtime-deps:8.0-jammy
runtime-deps:8.0-jammy-chiseled
runtime-deps:8.0-jammy-chiseled-icu
runtime
ICU is installed by default, except for Alpine. ASP.NET layer is the same.
runtime:8.0-alpine
runtime:8.0-bookworm-slim
runtime:8.0-cbl-mariner2.0-distroless
runtime:8.0-jammy
runtime:8.0-jammy-chiseled
It would be good if we could get a firm size diff between:
aot-deps:8.0-jammy-chiseled
aot-deps:8.0-jammy-chiseled-icu
and also:
runtime-deps:8.0-jammy-chiseled
runtime-deps:8.0-jammy-chiseled-icu
runtime-deps:8.0-alpine runtime-deps:8.0-alpine-aot runtime-deps:8.0-alpine-full runtime-deps:8.0-bookworm-slim runtime-deps:8.0-cbl-mariner2.0-distroless runtime-deps:8.0-cbl-mariner2.0-distroless-aot runtime-deps:8.0-cbl-mariner2.0-distroless-full runtime-deps:8.0-jammy runtime-deps:8.0-jammy-chiseled runtime-deps:8.0-jammy-chiseled-aot runtime-deps:8.0-jammy-chiseled-full
full
is a placeholder for a TBD term
I like aot-deps
since it will match aot-sdk
. However, that's not a big deal. Your approach works just as well.
However, I don't think we want to position AOT as having a runtime in the same way as CoreCLR.
However, I don't think we want to position AOT as having a runtime in the same way as CoreCLR.
I get what you are saying but to me they are logically the same type of image and that is evident when you inspect the contents and the fact that aots-deps and runtime-deps have a shared image. Just rename runtime-deps
if you don't like the implications runtime
has.
aot-deps
has two images, one of which is in common with runtime-deps
. The one unique to aot-deps
is the default one. That said, if and when we enable a web pages scenario for ASP.NET Core, then I suspect we'd make the other one the default.
runtime-deps
is fully a good name in CoreCLR land.
On further thought, I think just runtime-deps
is better. Simpler and less to explain.
That leaves just coming up with the terms.
full
all
extra
, extras
more
I think I like extra
best since it is the most descriptive. Unless we install ldap
and quic
, then the images are not full
or all
. extra
is more
not full
but curated.
We could also add Kerberos back in extra
. https://github.com/dotnet/dotnet-docker/issues/4751. Although I'm not sure that's super necessary.
Yes, I wasted 10 mins with a thesaurus.
We should follow the streaming TV naming and go with plus
. I'm only half kidding.
Going back to the name of runtime-deps
, what about naming that just dotnet-deps
? That may be redundant with the dotnet
portion of the repo name path but I don't like just deps
either.
I'll weigh in on the runtime-deps
and aot-deps
being the same image for some tags. We've never shared an image across repos before. Our infrastructure may or may not support that. There could be risk there.
extras
or plus
are equally good, IMO.
Some thoughts:
plus
branding in this or another timeline.extras
is less likely to be used again, based on past use: https://en.wikipedia.org/wiki/Windows_Ultimate_ExtrasHere's a use of "plus", not in tag but product: https://hub.docker.com/r/nginx/nginx-ingress
Here's a use of "extra": https://hub.docker.com/r/pandoc/extra
Separately, if we create such an image, we should consider adding tzdata
. It is a drop in the bucket compared to ICU.
https://github.com/dotnet/dotnet-docker/issues/4748#issuecomment-1675288023
We have a much broader story than before with trimming and these fancy deps images. I'd love to see us move more towards a "batteries included" model for our runtime images. However, this still needs more discussion. I might write something up.
There could be risk there.
That's only a risk if we try to use the same Dockerfile. Right?
That's only a risk if we try to use the same Dockerfile. Right?
Unknown. It will still be one image in separate repos. Not sure if that would have an impact or not.
On further thought, I think just runtime-deps is better. Simpler and less to explain.
@richlander - can you clarify what you mean? Are you referring to a single "deps" repo versus separate runtime-deps and aot-deps? Or were you referring to liking the name runtime-deps versus renaming it to something else?
Summary of a discussion on this topic in our dotnet-docker weekly standup.
aot-deps
and runtime-deps
repos as proposed earlier. They have too much overlap and would be difficult to describe. We will not rename runtime-deps
to something more abstract. There is not enough ROI to justify the disruption this would cause.runtime-deps
images will carry icu and tzdata. The exception is Alpine. Alpine will be considered part of our "lightweight" images until the point we add alpine-distroless images.runtime-deps
variants will be {default}/aot/extra.extra
variant at any time or possibly change the base image to be extra
(only during a major release). aot
sdk variant will be added.We shipped this, in the nightly
branch.
This recent issue got me thinking that we should consider providing an icu version of
aot-deps
and maybe evenruntime-deps
.https://github.com/dotnet/core/issues/8663
Today, we don't provide an ICU version of Alpine since we'd need two duplicate branches of images. This policy makes sense. When we think solely of self-contained, which all native aot apps are, then having an ICU image makes a lot more sense and avoids the need for the chisel tool. I see the cost/benefit tradeoff for ICU images being quite different (and more compelling) for
aot-deps
and consider same forruntime-deps
(maybe later).