Adding healthcheck to docker image

[zodac]

Updated the docker image with a HEALTHCHECK directive to avoid the need for users to specify one themselves in a docker-compose.yml (for example).

Used some typical values for the check, happy to tweak if necessary.

[CLAassistant]

All committers have signed the CLA.

[vabene1111]

hi, thanks for the PR.

I think we should probably use just /api/ as the URL as /openapi/ is a somewhat large and complext endpoint especially for people running this on low end devices.

Other than that it looks good to me from a code perspective.

Does this have any implications, what does the healtcheck do when it fails? how is the information useful in the first place?

[zodac]

Hi @vabene1111, thanks for the reply.

The only reason I used /openapi/ over /api/ is due to /api/ requiring authentication credentials, while /openapi/ is public. I guess there are a couple of options:

1. I could keep /openapi/ but change the wget request to use --spider, which sends a HEAD request rather than a GET, and wouldn't return the payload response. Should be less resource intensive for low-end devices
2. I could use /api/, and grep for 403 in the response. It might have false positives in some cases.

I don't know the flows as well as you would, so I preferred to use option 1. But happy to take your guidance on this.

---

Regarding usage, there is nothing by default that happens when the healthcheck fails. Personally, I use it so other docker services that rely on this container won't start if it's failing. For example, in the docker-compose described in the docs, the nginx container has a dependency on the web_recipes like so:

depends_on:
      - web_recipes

This only requires the web_recipes container to be specified, but if is failing, the nginx container still comes online. Instead you could specify like this:

    depends_on:
      web_recipes:
        condition: service_healthy

And this would require the web_recipes container to come up and pass a healthcheck before the nginx container to come online.

There are also services like docker-autoheal that can be used to automatically restart containers if healthchecks fail, but they require a healthcheck to be defined (where Tandoor would require it to be defined explicitly by the user).

There is the additional resource required to execute the healthcheck, but I think for an application of this size 30s is reasonable? I can always make that longer if you think it's a concern, or if you prefer, we can leave this PR out and keep the healthcheck optional.

[vabene1111]

Hi, thanks for your explanation. I think adding a healthcheck is probably a good practice so lets go ahead with it.

Lets go with option 1, it is indeed the only anonymous endpoint right now, maybe I could add a special health check one in the future.

[zodac]

Hi, thanks for your explanation. I think adding a healthcheck is probably a good practice so lets go ahead with it.

Lets go with option 1, it is indeed the only anonymous endpoint right now, maybe I could add a special health check one in the future.

Awesome, I've updated with --spider. :)

[dkadioglu]

Good idea, however, for me the container is unhealthy with the following in the logs:

web_recipes-1    | ::ffff:127.0.0.1 - - [13/Dec/2024:07:51:35 +0100] "GET
/openapi HTTP/1.1" 400 143 "-" "Wget"

[dkadioglu]

Good idea, however, for me the container is unhealthy with the following in the logs:

web_recipes-1    | ::ffff:127.0.0.1 - - [13/Dec/2024:07:51:35 +0100] "GET
/openapi HTTP/1.1" 400 143 "-" "Wget"

Good idea, however, for me the container is unhealthy with the following in the logs:

web_recipes-1    | ::ffff:127.0.0.1 - - [13/Dec/2024:07:51:35 +0100] "GET
/openapi HTTP/1.1" 400 143 "-" "Wget"

Sorry for the noise, seems it was a wrongly configured ALLOWED_HOSTS.