dotnet-docker
dotnet-docker copied to clipboard
dotnet
Consider defining a helper "health check" utility for distroless scenarios
The use of the HEALTHCHECK instruction often involves the use of a command that executes an HTTP request to the application in order to verify its health. That command might be curl or wget for Linux containers. This becomes problematic for distroless/chiseled containers that would likely want to exclude such commands. How then would a call be made to verify the health of the app?
One solution is to include a basic .NET application that execute the HTTP request (see https://github.com/dotnet/dotnet-docker/discussions/4296). Depending on the ubiquity of such a solution, it might make sense for .NET to provide its own implementation of this application that can be easily injected into .NET distroless/chiseled solutions.
I'll illustrate this with an example. Let's say .NET publishes an httpclient image that contains a .NET app which simply sends an HTTP request to a URL provided as an argument. It returns 0 if the request succeeds and 1 if it fails. A distroless implementation could consume this app like the following:
# Build stage excluded for brevity
...
FROM mcr.microsoft.com/dotnet/nightly/runtime-deps:7.0-jammy-chiseled
WORKDIR /app
COPY --from=build /app .
# Inject the .NET httpclient into the image to use for the health check
COPY --from=mcr.microsoft.com/dotnet/httpclient:7.0 /httpclient.exe /
HEALTHCHECK CMD [ "/httpclient.exe", "http://localhost/healthz" ]
ENTRYPOINT ["./app"]
I think it'd be important to understand the landscape of how customers are using health checks to determine the suitability of a pre-defined tool like this. We obviously don't want to be reimplementing curl in .NET but allowing for a little bit of behavior customization in order to fulfill a large portion of customer scenarios seems reasonable.
[Triage] As a first step, we'd like to provide documentation in the repo to help guide customer's on the pattern to implement this on their own in a way that doesn't depend on .NET providing a new tool. This is a low-cost solution and can also be used as a means to gather feedback from customers to determine the optimal solution that would meet their needs if we were to publish our own tool.
Does this affect Kubernetes' probes?
I'm not 100% sure, but I think the probes commands are handled outside the container, so it must work even in a distroless environment. Is it correct?
Does this affect Kubernetes' probes?
Not needed for Kubernetes. This is a docker compose need.
As far as I understand, having a way to ping the application from within the container is very important in the AWS space for people (like me) using ECS instead of EKS.
