graphql-engine
graphql-engine copied to clipboard
healthcheck doesn't respect port changes
Version Information
Server Version: v2.44.0 CLI Version (for CLI related issue):
Environment
Docker
What is the current behaviour?
In docker, I set the HASURA_GRAPHL_SERVER_PORT environment variable so that Hasura uses a port other than 8080. This works fine so that the server is running on a different port. However, the healthz periodic healthcheck always seems to use port 8080. This means that when I switch my port, even though everything is working, I get an unhealthy status in Docker. This also means that if something else uses port 8080, then it gets spammed with these healthz checks.
What is the expected behaviour?
If I change the port of the server to something else, then the healthz healthchecks should also use that port for checking.
How to reproduce the issue?
- Use Docker and set
HASURA_GRAPHL_SERVER_PORT=8081 - Start the container and wait a minute or two
- Check the health of the container and it'll be
unhealthy
Please provide any traces or logs that could help here.
Any possible solutions/workarounds you're aware of?
None that I know of outside of maybe wrapping the container in another container and recreating the healthcheck with the right port?
Keywords
healthz, 8080, healthcheck
Hi @its-a-feature, can you please confirm the env var name?
In docker, I set the
HASURA_GRAPHL_SERVER_PORTenvironment variable
It is not a valid env var name. HASURA_GRAPHQL_SERVER_PORT it is. See https://hasura.io/docs/2.0/deployment/graphql-engine-flags/reference/#server-port for more details.
Sorry, meant to reply sooner. Yes, I'm using HASURA_GRAPHQL_SERVER_PORT (it was a typo in this post). I know that's working too because the server port is being changed from 8080 to whatever I specify, but it's just the healthcheck isn't respecting it. Not sure if there's a different environment variable I should be setting for that or not
My initial thought is that since this is the Docker version, maybe a pre-compiled version of whatever is doing the healthcheck is hardcoded to 8080 or maybe the built-in healthcheck for the hasura container is hardcoded somewhere?
https://hub.docker.com/layers/hasura/graphql-engine/v2.36.8-ce.cli-migrations-v2/images/sha256-741c6ed6b2cdc16faf206df9e006a1ae34d1e31dbd6028ff2aa958597690a29e?context=explore
^ right there in the Docker image it's hardcoded to 8080
Oh! Okay. The cli-migrations image has the health check port hard-coded. Let's see if we can override the healthcheck defined in a dockerfile.
- Using docker run command - https://docs.docker.com/engine/containers/run/#healthchecks.
- In docker compose file - https://docs.docker.com/reference/compose-file/services/#healthcheck.
If this solves your issue, please feel free to close this ticket. Thank you.
I can make the mod in a custom Docker image/Compose file, but you should note in the docs for healthcheck that it doesn't respect the port changes. Similarly, when I try to use hasura-cli within the Docker image, it also doesn't respect the port change:
root@mythic_graphql:/test# hasura-cli metadata export
ERRO connecting to graphql-engine server failed
INFO possible reasons:
INFO 1) Provided root endpoint of graphql-engine server is wrong. Verify endpoint key in config.yaml or/and value of --endpoint flag
INFO 2) Endpoint should NOT be your GraphQL API, ie endpoint is NOT https://hasura-cloud-app.io/v1/graphql it should be: https://hasura-cloud-app.io
INFO 3) Server might be unhealthy and is not running/accepting API requests
INFO 4) Admin secret is not correct/set
INFO
FATA[0000] making http request failed: Get "http://localhost:8080/v1/version": dial tcp [::1]:8080: connect: connection refused
Is there some other variable or thing I can do to get the hasura-cli to respect the port change as well?
INFO 1) Provided root endpoint of graphql-engine server is wrong. Verify endpoint key in config.yaml or/and value of --endpoint flag
If not, please try this instruction to make hasura-cli to contact the engine URL with different port.
I just ran into this issue as well. Any updates on whether this will be addressed?