Repository navigation
Recommend currently available means for container HEALTHCHECK #36537
Replies: 5 comments 4 replies
|
I can't get this to work with 26.0.8? But there seems to be another problem too, as despite |
|
Hi @col-panic, I have developed this for KC v25.something, but it should generally work in any newer version. I see 2 differences in your example:
|
|
@vit-zikmund thanks for your response! Actually I was doing this just to see what really is returned from it's not correct. And using your code does Could you check, if any of this works for you in Keycloak 26? I also added this as a discussion point in #36526 - I just want to know if it's me or keycloak itself :) |
|
Hi @col-panic I see you managed to figure this out real quick in your other discussion. For the local readers, the necessity of the |
|
Based upon the discussion with @col-panic moved this to a discussion as well. |
|
Hello @shawkins, I've provided an updated command that works again (two variants actually). Is there some chance I could get the attention of someone who's responsible for the documentation, to review the proposal for the HEALTHCHECK suggestion in the docs? |
|
@vit-zikmund you would open an issue which references this discussion, then if you are able open a pull request that references that issue. |
|
According to quarkusio/quarkus#37582 (comment), the HTTP 1.1 protocol mandates the use of the |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Description
Hi, I was setting up keycloak in a docker compose deployment, where I wanted to have a working healthcheck. The documentation says to install
curlin such cases, but then again, that's rather convoluted and generally not recommended by another piece of docs. Compose doesn't have any external means of running a HTTP healthcheck, it merely offers to externally set the container'sHEALTHCHECKdirective, which runs a process on the same image.Trying to follow the latter recommendation I managed to develop this still pretty small oneliner which does the job using only
bash/coreutilsmeans:I believe, when proved right, this could become the new recommendation in the docs, or potentially even a
HEALTHCKECKdirective in the default image.Discussion
No response
Motivation
To tighten any potential attack surface even for plain container deployments.
Details
For the curious, here's how this works:
0(stdin).HEALTHCHECK's timeout (which should be definitely smaller than the usual TCP retry timeout).HEADrequest is sent to the socket usingprintf. This is supposed to always succeed, unless the send buffer of the socket is set ridiculously small on the target OS. In the other case it will just hang again, not being able to push all the bytes through, until that eventually happens or times out.grepto be the successful one. Only at this time it's return code (and the final) is 0.grepdoesn't match anything and returns 1.In order not to have the "client" close the TCP connection (for HTTP/1.1) after a successfully read message (while still reading the full socket's read buffer), I send the
connection: closeheader with the request, so the server closes the connection/socket once it fully responds. When this happens,grepends on its own after getting an EOF from the socket.Another option would be to call
grep -m1to exit after the 1st match, but that would result in the socket being closed without its read buffer being fully read, which usually warrants a RST packet back to the server. I prefer the graceful variant.All reactions