feat(monitoring) : les journaux des conteneurs remontent à nouveau #26
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/container-logs"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Un conteneur système a son propre
journald: depuis que les services y sont descendus (PR #24 et #25), l'Alloy des nœuds ne voyait plus rien d'eux. Ni un Caddy qui refuse de démarrer, ni une authentification AppRole refusée, ni un rendu de template en erreur — c'est-à-dire précisément ce qui n'a de trace que dans un journal.Chaque conteneur porte donc son Alloy, en mode journaux seulement.
baseest scindéLa PR #24 avait refusé de l'appliquer aux conteneurs et écrit pourquoi : il est fait pour un routeur — sysctl de routage,
wireguard-tools,tcpdump. Mais c'est lui qui posait le dépôt Grafana dont Alloy a besoin.Les deux dépôts tiers partent donc dans
apt_sources, dontbasedépend et qui les active tous les deux : rien ne change pour un nœud, et le conteneur ne prend que Grafana. Il n'installe pas Bird depuis CZ.NIC — celui de l'ingress prend la Bird 3 de Debian.Les deux obstacles, mesurés avant d'écrire une ligne
loki.thystips.xyzrésout vers un A privé et un AAAA public. Un conteneur n'a aucune IPv6 routable vers internet — sa seule adresse v6 est DN42 — donc laissé à RFC 6724 il tentait l'IPv6 :D'où
gai.conf, le même fichier que sur les nœuds. ⚠ Le gabarit passe dansansible/templates/plutôt que d'être copié : une seule ligneprecedenceremplace toute la table par défaut, et deux copies d'une table de préférence d'adresses ne divergent pas bruyamment — elles changent silencieusement quel chemin le trafic prend. Il nommait la variable debase, ce qui a échoué franchement dans un conteneur ; il prend maintenant un paramètre neutre.L'ingest est sur le plan privé, donc dans les plages que notre propre règle ferme. Une ligne de plus à côté de celle de
ca1, avec sa ligne de matrice. ⚠ Une adresse et pas un nom — nftables n'en prend pas d'autre, et un changement côté infrastructure se paierait ici en silence.Deux pièges de supervision évités
caddy.servicesort de la liste des unités des nœuds. L'y laisser aurait été pire qu'inutile : un filtre qui ne matche plus rien ne se distingue pas d'un service silencieux, donc la supervision aurait eu l'air de couvrir le tier d'ingress sans plus rien voir de lui.instancedistingue le conteneur de son nœud.dn42_nodevaut ici le nom de l'hôte — voulu partout ailleurs, un service en conteneur répondant pour ce nœud — mais s'en servir comme instance aurait mélangé deux journaux sous une étiquette,openbao-agent.serviceexistant des deux côtés.Vérifié
« Pas d'erreur dans le journal d'Alloy » ne suffisait pas. Ses compteurs, eux, tranchent :
avec un
HTTP 204de Loki sur le tenantdn42. Témoin négatif : le SSH d'un nœud depuis un conteneur reste fermé.changed=0sur les douze hôtes.Au passage
render-checkgagne les gabarits partagés : il ne parcourt que les rôles, doncgai.conf.j2n'était plus vérifié par personne une fois déplacé — un gabarit qu'aucun check ne rend est un gabarit qui échoue sur un routeur à la place.Le push direct a été déployé et mesuré avant d'être remplacé — il marchait. Ce qui l'a fait retirer, ce sont deux coûts que CHAQUE conteneur à venir aurait payés (`dns_rec`, le frontal LG, le coffre) : 1. Le mot de passe de l'ingest en clair dans chaque conteneur. Quatre copies de plus d'un secret qui n'en avait que quatre. 2. Une ouverture vers le plan privé. Le pont est NATé, donc une règle ne peut porter que sur la DESTINATION : ouvrir l'ingest à un conteneur, c'est l'ouvrir à tous les conteneurs du nœud — vers un service qui accepte des écritures. Le nœud reçoit sur `loki.source.api` et réexpédie avec SES identifiants. Le conteneur ne parle qu'à son hôte ; la ligne `10.2.70.168:443` disparaît de `nftables_incus_allowed_private`. ⚠ LE NŒUD ÉCOUTE, ce que le dépôt affirme partout ailleurs qu'il ne fait pas. La nuance qui rend ça acceptable est l'ADRESSE : `10.42.0.1`, le pont NATé, jamais le wildcard — que `tcp_l3mdev_accept=1` rendrait joignable depuis tout l'overlay. Vérifié dans les deux sens : `ss` ne montre que `10.42.0.1:3500`, et le port est fermé depuis la VRF d'un autre nœud. ⚠ PAS D'AUTHENTIFICATION sur ce port, et c'est assumé : tout conteneur du nœud peut écrire dans notre tenant. Ce sont nos conteneurs, le pare-feu borne qui atteint le port, et une paire d'identifiants de plus aurait rendu au conteneur le secret que ce relais existe pour lui retirer. `use_incoming_timestamp` : sans lui, un redémarrage du relais réécrirait à l'instant présent des lignes vieilles de plusieurs heures — `max_age` fait rattraper jusqu'à 12 h au démarrage d'un conteneur. `gai.conf` RESTE dans le conteneur, mais sa raison change et le commentaire le dit : ce n'est plus Loki, dont l'adresse est devenue locale, c'est `ca1.thystips.xyz` — même profil A privé / AAAA public (`10.1.70.20` et `2a0c:b641:112:70::20`, mesuré), et c'est le nom que le descellement par transit résout. C'est de la configuration de MACHINE, pas de service. Vérifié : zéro ligne `password`/`username` dans les quatre conteneurs, 42 entrées envoyées par chacun avec HTTP 204 du relais, 44 reçues côté nœud, 478 réexpédiées vers Loki, aucune perte sur aucun des deux sauts. `changed=0` sur les douze hôtes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9