2 ms·
I build my own Apache container images (long story, Nginx and Caddy are okay too for most purposes) and I need to do health checks, so I also had to think about
by KronisLV 3y ago
I build my own Apache container images (long story, Nginx and Caddy are okay too for most purposes) and I need to do health checks, so I also had to think about this.
When I launch a container that's supposed to sit in front of multiple other containers as a reverse proxy or just serve static files, I need to know whether the Apache process in it is working and actually serving files. This is regardless of the rest of the configuration and whether every site is up: for example, if 19 out of 20 sites are configured correctly and are served, the failing one can be addressed separately later.
In my case, that's as easy as the following:
healthcheck:
test: "curl http://127.0.0.1:80 | grep 'Apache2 is up and running' || exit 1"
interval: 10s
timeout: 10s
retries: 6
start_period: 5s
(there are also separate external uptime checks for the actual sites with domains and HTTPS, too)
I serve some HTML files by default in every container with specific contents, in addition to any domains that the web server has configured. If I can access these default files, that means that the web server is up and I can then think about testing the rest of the configuration myself. In this case, I decided to check the file contents instead of the status code.
Frankly, you can get the same result with just status codes (probably a 200 IMO because of how simple it is), or maybe some specific HTML contents in the default page to identify whether you're talking to the correct web server instance and have deployed it in the right place, maybe even page contents that have been generated by something like PHP-FPM to check whether scripts get executed correctly (also like testing OpenResty with Lua) if you need that sort of thing.
Whatever works for you.