Consider defining a helper "health check" utility for distroless scenarios

[mthalman]

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.

[mthalman]

[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.

[64J0]

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?

[richlander]

Does this affect Kubernetes' probes?

Not needed for Kubernetes. This is a docker compose need.

[Kralizek]

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.