When monitoring an Armadietto installation, one must pick a URL. So far, I’ve been using / (the root) However, this just checks that some HTTP server is running, and allows false positive tests. For example, if you’re using Apache or NginX as a reverse proxy, but the configuration is wrong and Apache or NginX is actually serving static files from /var/www/http, you’ll probably get status 200 and the default page. If the health check allows you to check the response, you can check that the response include “Armadietto”.
However, some systems (such as a DigitalOcean load balancer) don’t let you check for strings in the response. If signups are enabled, the path /signup can be checked.
If signups are disabled, one can create a test user with a public document, and check for that.
Are there any other paths that can return a 200 status without authentication?
This is an interesting problem.
Are you able to specify any headers in the health checks? I know that
I know the way I’ve seen this problem solved is a server creating an endpoint explicitly for the purposes of health checks (eg it checks that the server is able to connect to its db/any required services/etc). If you want to make sure malicious actors can’t abuse the endpoint, you can require a secret to be provided in the query string, eg: https://myarmadietto.com/healthz?secret=abc123
Yes, we probably ought to add an endpoint just for upness checks. I was hoping there was a clever way to avoid that. :-S
Hey @DougReeder, one of my PRs back in the day added an explicit healthcheck endpoint “middleware”… but we decided against it since a public folder read from a well know user accomplishes same.
The reason this works well for rs.overhide.io cluster, which is running my luchetto fork of arma, is that the luchetto fork is geared towards using kubernetes to orchestrate. Each node in the cluster is health checked by the k8s orchestrator to return the public file, which exercises the app and the storage.
To instrument this setup one needs to just create a sysop user with a public status.txt file and configured k8s readiness and liveness probes to fetch it.
This can be seen in the sample deployment repo along with the scripts (oh-arma.ps1):
Yes, I’m thinking we may want to incorporate your health check in the main fork.
