webp-sh / webp_server_go

Go version of WebP Server. A tool that will serve your JPG/PNG/BMP/SVGs as WebP/AVIF format with compression, on-the-fly.
https://docs.webp.sh
GNU General Public License v3.0
1.79k stars 174 forks source link

basic health endpoint #295

Closed ktzsolt closed 10 months ago

ktzsolt commented 10 months ago

Created a /health endpoint so this can be used in k8s with http readiness/liveness probes. In router.go I added:

    // /health endpoint
    if reqURI == "/health" {
        c.SendString("UP!")
        c.SendStatus(http.StatusOK)
        return nil
    }

I never used go before, but the docker image based on the Dockerfile is built and the webp server is running as it should be, /health url returns "UP!" with HTTP 200.

n0vad3v commented 10 months ago

Thanks for contributing, currently you can just rely on Pod status to determine whether WebP Server Go is running in healthy state.

May we know a little bit more on your use case on this?

ktzsolt commented 10 months ago

I am using this pattern: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

A common pattern for liveness probes is to use the same low-cost HTTP endpoint as for readiness probes, but with a higher failureThreshold. This ensures that the pod is observed as not-ready for some period of time before it is hard killed.

I run the webp as a sidecar container in the pod so when webp would be overwhelmed with requests and can't serve requests or not fast enough, I just want the pod to go into "not ready" state and let the new requests served by other pod replicas until it is able to server requests again.

Also the go webp server process (/usr/bin/webp-server) might be up and running so the container is up and running but the server process might not serve request at all due to some unknown error or bug in go itself, any 3rd party package used in the code or in the code itself. Even in the containers OS packages can be bugs.

I always use readiness, liveness and startup probes and when I have to fall back to exec probe (write file into container, and check if it exists, or use bash script to check if some file has something in it) I think it is "code smell". I would have also done exec probe or TCP probe here too, but I just thought why not check out the code and try to write a basic /health HTTP endpoint myself.

I guess these scenarios will never happen to me, but "anything that can go wrong will go wrong".

n0vad3v commented 10 months ago

I got you, will add this feature.

There is a better way to add this endpoint, at router, I've done a PR on https://github.com/webp-sh/webp_server_go/pull/296

ktzsolt commented 10 months ago

Excellent, thanks!

n0vad3v commented 10 months ago

We've released https://github.com/webp-sh/webp_server_go/releases/tag/0.10.2 that includes /healthz endpoint.