[Feature] healthcheck command

[LucaRickli]

Use case

Docker HEALTHCHECK

Description

Headscale does not come with a (easy) way of checking health using only the CLI. This is especially painful when running Headscale inside a docker container

Contribution

• I can write the design doc for this feature
• I can contribute this feature

How can it be implemented?

Should be pretty simple as it could tie into the already existing /health endpoint

[kradalby]

Can't you just use curl?

[LucaRickli]

Can't you just use curl?

@kradalby Unfortunately not an option for some Environments. For example: inside the provided distroless Docker container (non debug) there is no curl nor shell.

[kradalby]

fair enough, I wont prioritise this but sounds like a good issue for someone who wants to help out.

If this is implemented, it needs to be added to the API, and if we do that, we should probably remove the old endpoint and only use the API one for other uses.

Alternatively, the CLI can not use the gRPC API at all and just call the endpoint that currently exists. The downside of that is that you dont get to verify that the gRPC stack works, so I would prefer the first option.

[mikelococo]

As a workaround for end-users, bash at least is included in docker.io/headscale/headscale:0.22.3. This enables using /dev/tcp to check if the API port is open via something like (assuming you're using the default API port): bash -c 'cat < /dev/null > /dev/tcp/localhost/8080'. See https://medium.com/@stefanos.kalandaridis/bash-ing-your-network-f7069ab7c5f4 for a decent primer on how it works.

This is among the weakest of healthcheck options in that it simply verifies that SOMETHING is able to accept a tcp connection on the API port. It says nothing about the health of the gRPC stack or any in-memory or on-disk state. It also says nothing about DERP, which could maybe be interrogated via /dev/udp but doing so requires knowing a valid message to send that will elicit a response and not leak resources along the way. I haven't configured a derp check myself.

This isn't a high-quality replacement for the stronger checks proposed in other comments... but it's start that allows monitoring frameworks to check that the API is at least healthy enough to complete a 3-way TCP handshake in image-flavors that have bash available.