Replies: 3 comments 1 reply
-
Hi @paulmey. Does dotnet-monitor address your use-case? It is a sidecar container that contains endpoints for The image is published out of this repo and you can find the tags here: https://github.com/dotnet/dotnet-docker/blob/main/README.monitor.md |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I've seen these tools installed several times. I think it would very useful to have at least one image that contained them so that it would be trivial to do a one-line |
Beta Was this translation helpful? Give feedback.
-
Describe the Problem
Our team prefers to have diagnostics tools available in production images to be able to root-cause and diagnose issues without needing to download bits from the internet into production environments. Therefore,
dotnet-trace
,dotnet-counters
,dotnet-gcdump
anddotnet-dump
are downloaded in an SDK image during build usingdotnet tool install ...
. Specific versions of the tools are installed downloaded. The final aspnet image copies the downloaded tools from the SDK image.Recently security restrictions are now in place to even lock down internet access during build time and require teams to use Azure DevOps Artifact feeds instead of nuget.org. This is inconvenient in container builds, because now tokens have to be acquired and passed into the container builds. For pipelines this is not that hard, but now users who want to build locally also need tokens (which is also restricted (i.e. made harder, but not impossible) due to security concerns).
Describe the Solution
It would be convenient to have the core set of tools (assuming they include the ones above) also available as a container image so that these tools can be more easily included in container builds in restricted environments where unauthenticated nuget mirrors are not available.
Beta Was this translation helpful? Give feedback.
All reactions