You almost certainly don’t need this page. The compose file described in
Using Docker already gives you every checker we
ship, with the exact same results. Splitting them into containers adds no
feature; it only changes where they run. (Adding a checker that is not part
of happyDomain is a different question, and the answer there is usually a
plugin.)
Why this exists
happyDomain has to know a checker before it can run it. There are exactly
two ways to register one:
built-in, compiled into the happyDomain binary. Every checker we ship is
available this way, and it is the default;
plugin, a shared library loaded at start-up from a directory given with
-plugins-directory. This is the only way to register a checker that isn’t
part of happyDomain, such as one written in-house. It requires a -cgo build
of happyDomain and a platform where Go supports plugins.
Once a checker is registered, you can decide where its work runs: inside the
happyDomain process (the default), or in a standalone container it delegates
to over HTTP. That is what this page is about.
A container does not register a checker
Running happydomain/checker-<something> and setting its endpoint only works
because that checker is already known to happyDomain. Pointing an endpoint at a
checker the server has never heard of does nothing: a custom checker must be
loaded as a plugin first, and only then may it be delegated to a container.
Take checker-ping, which
verifies that every IP address of a zone answers ICMP within a given delay. It
is already inside your happyDomain binary, whichever deployment you choose. If
you also run the happydomain/checker-ping container and set
HAPPYDOMAIN_CHECKER_PING_ENDPOINT, the built-in checker simply forwards the
work to that container instead of doing it itself. Same checks, same rules,
same output.
When it’s worth it
The split deployment makes sense when:
you monitor thousands of zones and want to scale a hot checker
horizontally, independently from the rest of happyDomain;
you need strong process isolation between checks, for example because a
checker needs elevated network capabilities (NET_RAW for ICMP) that you
don’t want granted to the main process;
you want to pin, upgrade or roll back a single checker on its own release
cycle.
What it costs
Memory. Around thirty extra containers, each with its own runtime, for a
feature set strictly equal to the single-container one.
Operations. Thirty more images to pull, watch and upgrade.
Debugging. When a check fails, the cause may now be the checker, the
container, the network between them, or a stale endpoint variable. That
investigation is significantly more painful than reading a single log stream.
If none of the reasons above applies to you, go back to
Using Docker.
How delegation works
HAPPYDOMAIN_CHECKER_<ID>_ENDPOINT is an option of a registered checker,
not a way to declare one. For every checker happyDomain knows about (built-in
or loaded from a plugin), setting that variable makes it forward the collection
to the given URL instead of doing the work itself; leaving it empty keeps the
checker running locally inside the happyDomain process. <ID> is the checker’s
own identifier; if it doesn’t match a registered checker, the variable is
simply ignored.
You can mix both freely: delegate only the checkers you actually want to
isolate, and leave the rest running in-process.
Two checkers rely on additional third-party backends, independently of this
choice:
Zonemaster (checker-zonemaster) queries the zonemaster/backend
service. The HAPPYDOMAIN_CHECKER_ZONEMASTER_ZONEMASTERAPIURL variable tells
the checker where that backend listens.
Matrix federation tester (checker-matrix) queries the
matrixdotorg/federation-tester-backend service. The
HAPPYDOMAIN_CHECKER_MATRIXIM_FEDERATIONTESTERSERVER variable points to its
report endpoint.
The procedure is the same as for the standard deployment
(Updating the stack): first check
whether the file you started from has changed, then
docker compose up -d --pull always
Be aware that here, step one is on you: this file is not generated. When we ship
a new checker, its built-in version arrives with the happyDomain image, but
nothing adds the matching container and its _ENDPOINT variable to your file.
Re-read this page after each upgrade and port the new services you want to keep
delegating; a checker you don’t list simply keeps running in-process, which is a
perfectly valid outcome.
Optional: happyDeliver
If you run a happyDeliver instance for mail-flow
monitoring, uncomment the HAPPYDOMAIN_CHECKER_HAPPYDELIVER_ENDPOINT line and
add the corresponding service:
The checker-blacklist service works without API keys (it uses DNS-based
blocklists by default), but you can enable additional sources (Google Safe
Browsing, VirusTotal, abuse.ch URLhaus) by configuring the matching admin
options from the happyDomain administration interface once the stack is running.