Healthcheck curl isn't effective and cause unhealthy container about docker-pdns HOT 3 CLOSED

Hello @leleobhz, thank you for the detailed report. I'm proposing to change the health check to CMD ["curl", "-fsSLo", "/dev/null", "http://127.0.0.1:9494"]
This queries python app directly via uwsgi, skipping caddy. It checks if python app is working as well as the connection to the database. What do you think? Would that work in your setup?

from docker-pdns.

Hello @leleobhz, defining separate Caddy port with health check sounds like a good idea. The solution I chose for now bypasses Caddy completely, so there should be no issue with redirects. I think this is good enough for now, we can revisit later if needed. Cheers.

from docker-pdns.

Hello @leleobhz, thank you for the detailed report. I'm proposing to change the health check to CMD ["curl", "-fsSLo", "/dev/null", "http://127.0.0.1:9494"] This queries python app directly via uwsgi, skipping caddy. It checks if python app is working as well as the connection to the database. What do you think? Would that work in your setup?

Hello @pschiffe !

Sorry by late answer. I can try because I don't know if it avoids the 302 redirect issue.

I personally think about what I'm testing. If I'm testing admin frontend+backend availability, curl to a heath endpoint is the best way to do (And implement a /health in Caddy as example to return 200 or 500 depending of backend awnser), But If we test only for port being opened or close (Check if Caddy crashed, as example), bash test is more than enough.

Anyways, if this brace the case of 302 redirection, I think it satisfy this issue report and we can discuss this with time if you want.

from docker-pdns.