Exécuter les vérificateurs dans des conteneurs séparés
Ce n’est pas le déploiement par défaut
Vous n’avez très probablement pas besoin de cette page. Le fichier
docker compose décrit dans Avec Docker vous donne
déjà tous les vérificateurs que nous distribuons, avec exactement les mêmes
résultats. Les éclater en conteneurs n’ajoute aucune fonctionnalité : cela
change seulement l’endroit où ils s’exécutent. (Ajouter un vérificateur qui ne
fait pas partie d’happyDomain est une autre question ; la réponse est
généralement un greffon.)
À quoi ça sert
happyDomain doit connaître un vérificateur avant de pouvoir l’exécuter. Il
n’existe que deux façons de l’enregistrer :
intégré (built-in), compilé dans le binaire happyDomain. Tous les
vérificateurs que nous distribuons sont disponibles ainsi, et c’est le
comportement par défaut ;
greffon (plugin), une bibliothèque partagée chargée au démarrage depuis
un répertoire indiqué par -plugins-directory. C’est le seul moyen
d’enregistrer un vérificateur qui ne fait pas partie d’happyDomain, par
exemple développé en interne. Cela nécessite une version -cgo d’happyDomain
et une plateforme où Go prend en charge les greffons.
Une fois le vérificateur enregistré, vous décidez où son travail s’exécute :
dans le processus happyDomain (par défaut), ou dans un conteneur autonome
auquel il délègue en HTTP. C’est l’objet de cette page.
Un conteneur n’enregistre pas un vérificateur
Faire tourner happydomain/checker-<quelque-chose> et définir son point d’accès
ne fonctionne que parce que ce vérificateur est déjà connu d’happyDomain.
Pointer un point d’accès vers un vérificateur dont le serveur n’a jamais
entendu parler ne produit rien : un vérificateur maison doit d’abord être
chargé sous forme de greffon, et seulement ensuite il pourra être délégué à un
conteneur.
Prenons checker-ping, qui
vérifie que chaque adresse IP d’une zone répond au ping dans un délai donné. Il
est déjà présent dans votre binaire happyDomain, quel que soit le déploiement
choisi. Si vous faites également tourner le conteneur
happydomain/checker-ping et définissez HAPPYDOMAIN_CHECKER_PING_ENDPOINT, le
vérificateur intégré se contente de transmettre le travail à ce conteneur au
lieu de l’effectuer lui-même. Mêmes vérifications, mêmes règles, mêmes
résultats.
Quand cela vaut le coup
Le déploiement éclaté prend son sens lorsque :
vous surveillez des milliers de zones et souhaitez mettre à l’échelle
horizontalement un vérificateur très sollicité, indépendamment du reste
d’happyDomain ;
vous avez besoin d’une forte isolation des processus, par exemple parce
qu’un vérificateur requiert des capacités réseau élevées (NET_RAW pour
l’ICMP) que vous ne voulez pas accorder au processus principal ;
vous voulez figer, mettre à jour ou revenir en arrière sur un seul
vérificateur, sur son propre rythme de publication.
Ce que cela coûte
La mémoire. Une trentaine de conteneurs supplémentaires, chacun avec son
propre environnement d’exécution, pour un ensemble de fonctionnalités
strictement identique à celui du conteneur unique.
L’exploitation. Une trentaine d’images de plus à récupérer, surveiller et
mettre à jour.
Le débogage. Quand une vérification échoue, la cause peut désormais être
le vérificateur, le conteneur, le réseau entre les deux, ou une variable
d’environnement obsolète. Cette investigation est nettement plus pénible que
la lecture d’un unique flux de journaux.
Si aucune des raisons ci-dessus ne vous concerne, revenez à
Avec Docker.
Comment fonctionne la délégation
HAPPYDOMAIN_CHECKER_<ID>_ENDPOINT est une option d’un vérificateur
enregistré, et non un moyen d’en déclarer un. Pour chaque vérificateur
qu’happyDomain connaît (intégré ou chargé depuis un greffon), définir cette
variable lui fait transmettre la collecte à l’URL indiquée au lieu de faire le
travail lui-même ; la laisser vide maintient le vérificateur dans le processus
happyDomain. <ID> est l’identifiant propre du vérificateur : s’il ne
correspond à aucun vérificateur enregistré, la variable est simplement ignorée.
Les deux approches se mélangent librement : ne déléguez que les vérificateurs
que vous souhaitez réellement isoler et laissez les autres s’exécuter dans le
processus.
Indépendamment de ce choix, deux vérificateurs s’appuient sur des services tiers
supplémentaires :
Zonemaster (checker-zonemaster) interroge le service zonemaster/backend.
La variable HAPPYDOMAIN_CHECKER_ZONEMASTER_ZONEMASTERAPIURL indique au
vérificateur l’adresse de ce service.
Matrix federation tester (checker-matrix) interroge le service
matrixdotorg/federation-tester-backend. La variable
HAPPYDOMAIN_CHECKER_MATRIXIM_FEDERATIONTESTERSERVER pointe vers son point
d’accès de rapport.
La procédure est la même que pour le déploiement standard
(Mettre à jour la pile) :
vérifiez d’abord si le fichier dont vous êtes parti a changé, puis
docker compose up -d --pull always
Attention, ici la première étape vous incombe : ce fichier n’est pas généré.
Lorsque nous publions un nouveau vérificateur, sa version intégrée arrive
avec l’image happyDomain, mais rien n’ajoute pour autant le conteneur
correspondant ni sa variable _ENDPOINT à votre fichier. Relisez cette page
après chaque mise à jour et reportez-y les nouveaux services que vous souhaitez
continuer à déléguer ; un vérificateur que vous ne listez pas continue
simplement de s’exécuter dans le processus, ce qui reste parfaitement valable.
Optionnel : happyDeliver
Si vous exploitez une instance happyDeliver pour
surveiller les flux e-mail, décommentez la ligne
HAPPYDOMAIN_CHECKER_HAPPYDELIVER_ENDPOINT et ajoutez le service correspondant :
Le service checker-blacklist fonctionne sans clé API (il utilise des listes
de blocage DNS par défaut), mais vous pouvez activer des sources supplémentaires
(Google Safe Browsing, VirusTotal, abuse.ch URLhaus) en configurant les options
d’administration correspondantes depuis l’interface d’administration de
happyDomain une fois la pile démarrée.