Self-healthcheck for Caddy Docker Scratch image


(Quentin McGaw) #1

Hi all !

I am working on a Docker image with Caddy, and I would like to add a Docker healthcheck to the image.
One would usually use a program such as wget to check the server works correctly on port 80 for example. In my case, scratch is my base image (just a filesystem) so there is no wget.

Ideally, the Docker container would launch the normal Caddy server caddy at start, and run caddy healthcheck periodically. This second would check the already running Caddy instance is working normally. If a problem occurs, do os.Exit(1), otherwise os.Exit(0). Is there any chance you could implement a simple healthcheck command? If not, would that be implementable as plugin (directions would be appreciated!) ?

Thanks !


(Matthew Fay) #2

Hmm. This could be doable. But I wonder if it would be simpler to add in an extra binary - you could compile wget into the scratch container or download a curl binary perhaps.


(Quentin McGaw) #3

Indeed, but I thought that checking some elements internally could be more interesting for a healthcheck than an external test with wget to the http Caddy server. Would that be achievable via a plugin? Or would a pull request be considered to implement this? Thanks !


(Matthew Fay) #4

Well, if you want a caddy -healthcheck command, you’re starting a new instance of Caddy to do that, which would presumably then communicate with the site-serving Caddy instance to figure out what it needs to know.

You might be thinking along the lines of having the Caddy server collect its list of listeners and pass them to the Caddy healthchecker for the latter to run tests against, maybe?

Or maybe you could just have the Caddy healthcheck parse the Caddy server’s Caddyfile and figure out the hostname / listener configuration itself, then test them all and exit.

Lots of ways to go about it, I think. I know that PRs are always welcome on the Caddy repository.


(Quentin McGaw) #5

Indeed you are right, another instance would not really know the status of the first instance so that’s silly.
Or the Caddy server (first instance) could have a build-in healthcheck HTTP route returning JSON information about its internal health, and a simple HTTP client program could send a GET request to it. The only problem is that this could cause conflict and add security risks. I will dig into that. Thanks !