-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider defining a helper "health check" utility for distroless scenarios #4300
Comments
[Triage] |
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? |
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. |
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 becurl
orwget
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: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.
The text was updated successfully, but these errors were encountered: