dotnet-docker
dotnet-docker copied to clipboard
dotnet
Produce Aspire dashboard images
Having Aspire dashboard images readily available improves the UX for deployment into any environment that supports the resource server or just wants an easy to deploy otlp server.
Related Aspire issue
Issues
- https://github.com/dotnet/dotnet-docker/pull/5148
- https://github.com/dotnet/aspire/issues/2035
- https://github.com/dotnet/dotnet-docker/issues/5153
- https://github.com/dotnet/dotnet-docker/issues/5154
- https://github.com/dotnet/dotnet-docker/issues/5155
- https://github.com/dotnet/dotnet-docker/issues/5156
- https://github.com/dotnet/dotnet-docker/issues/5335
@joperezr - Can you help define the following?
- Usage scenarios
- Is it expected that anyone will build on top of this image (e.g. use it in a FROM)? Will this be strictly an appliance style image?
- Do you expect anyone will want to shell into the image? Can/should it be a distroless image?
- Repository name
- Supported distros and architectures
- Will first parties be interested? Are Mariner images needed? Can always be added later.
This will help inform what images are needed and the tag names.
Adding @davidfowl so he can cross-check my replies here.
Usage scenarios Is it expected that anyone will build on top of this image (e.g. use it in a FROM)? Will this be strictly an appliance style image? Do you expect anyone will want to shell into the image? Can/should it be a distroless image?
No, we don't expect people to derive from the image, and we do believe it is an appliance style image. Shelling into the image will in large be mostly for debugging purposes in case of troubleshooting, but the average user isn't expected to do so. As far as distroless image, I'm not sure I understand the question; My intuition says that given it is an appliance style image, as long as it works in all different platforms and archs I don't think we really care about what the base distro is.
Repository name
Do we have an existing convention? Looks like at least the docker-monitor one is dotnet/monitor, so I'm assuming ours could be something like dotnet/aspire-dashboard
Supported distros and architectures Will first parties be interested? Are Mariner images needed? Can always be added later.
Yes. Main scenario for now is ACA (Azure Container Apps), but we do see in the future first parties adopting and using this image.
My intuition says that given it is an appliance style image, as long as it works in all different platforms and archs I don't think we really care about what the base distro is.
The smaller the better
Do we have an existing convention? Looks like at least the docker-monitor one is dotnet/monitor, so I'm assuming ours could be something like dotnet/aspire-dashboard
I like this.
Yes. Main scenario for now is ACA (Azure Container Apps), but we do see in the future first parties adopting and using this image.
and 3rd parties
My intuition says that given it is an appliance style image, as long as it works in all different platforms and archs I don't think we really care about what the base distro is.
The advantage of using distroless images is they are very small thus have a reduced attack surface area and are faster to pull. See our recent blog post announcing Ubuntu distroless images for additional details. I think distroless is an attractive option here. I asked about scenarios because it determines if including bash is necessary or not.
Do we have an existing convention? Looks like at least the docker-monitor one is dotnet/monitor, so I'm assuming ours could be something like dotnet/aspire-dashboard
That was my initial idea as well. I will propose a shorter alternative as having shorter repository names is attractive - dotnet/aspire-dash. It feels similar to dotnet/runtime-deps in that we don't spell out dependencies.
Yes. Main scenario for now is ACA (Azure Container Apps), but we do see in the future first parties adopting and using this image.
It sounds like producing Ubuntu Chiseled and Mariner distroless images is what we are gravitating towards. What about architectures? Both amd64 and arm64?
CC @richlander, @lbussell for awareness
I will propose a shorter alternative as having shorter repository names is attractive -
dotnet/aspire-dash.
This is a nitpick, but may be important to others. When I read that out loud, I say "dotnet slash aspire dash dash". The repeated "dash" might be confusing to others when describing the repository verbally.
Yes, I think we care about arm64 as well, especially if it is relatively straight forward to also support it.
I don't have strong opinions regarding the repository name, so either the shorter or longer version works for me, whichever you folks recommend.
I will propose a shorter alternative as having shorter repository names is attractive -
dotnet/aspire-dash.This is a nitpick, but may be important to others. When I read that out loud, I say "dotnet slash aspire dash dash". The repeated "dash" might be confusing to others when describing the repository verbally.
Thanks for pointing that out. The problem still exists in a way with it spelled out - "dotnet slash aspire dash dashboard"
+1 to @jander-msft
aspire-dash is an objectively bad name, particularly only to save five characters. Don't do it.
Oh right, we're the folks that own https://dot.net. Same naming committee.
Oh right, we're the folks that own https://dot.net/. Same naming committee.
Lol! I swear I was going to make a comment about https://get.dot.net/ above.
I'm happy to ask, but I doubt that they will. "Aspire Portal" could be confusing and misleading, since what it really is, is a dashboard where you can see your Aspire Application and monitor it's logs, telemetry, etc. We do plan to have a centralized documentation site for Aspire, which we may want to refer to as the "Aspire Portal" in the future, so wouldn't want the dashboard to conflict with that.
Correct, it's a dashboard, lets use the name aspire-dashboard and deal with the fallout.
+1
Also, "Azure Portal" seems to have the "portal" name locked up for us.
Since we're talking about portals, I guess that brings up the question of high vs low fantasy. I'm more into high fantasy so have a general aversion to portals. None of this platform 9 & 3/4 business.
[Triage] We'll use this issue as an epic to track the .NET Docker side of the aspire-dashboard containers work. All of the (future) issues for aspire-dashboard images should be linked here.
I'm happy to ask, but I doubt that they will. "Aspire Portal" could be confusing and misleading, since what it really is, is a dashboard where you can see your Aspire Application and monitor it's logs, telemetry, etc. We do plan to have a centralized documentation site for Aspire, which we may want to refer to as the "Aspire Portal" in the future, so wouldn't want the dashboard to conflict with that.
Why don't rebrand as Aspire APM instead?
