Skip to content

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

@mthalman

Description

@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 #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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    Status

    Post Release

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions